summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/engine/engine.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Simplify engine.htb2024-03-021-45/+1
| | | | | | Garbage collect some more of this former horror show. ok jsing
* Unifdef OPENSSL_NO_ENGINE in engine.htb2023-11-191-566/+8
| | | | | | | Also rip out all the gross, useless comments. There's still too much garbage in here... ok jsing
* Move the ENGINE_new() prototype a line downtb2023-08-041-2/+2
|
* Excise ECDH_METHODtb2023-07-281-13/+1
| | | | | | | | Unlike ECDSA_METHOD, this has been unused forever but kind of needed to stay for symmetry with ECDSA_METHOD. Now we can finally take it behind the barn and remove its tendrils into ENGINE. ok jsing
* Remove ECDSA_METHODtb2023-07-281-13/+1
| | | | | | | | After smtpd (in base) and libtls finally switched from ECDSA_METHOD to EC_KEY_METHOD, much of the ECDSA_METHOD code was neutered. Remove the remaining public API as well as numerous tentacles into ENGINE. ok jsing
* Provide a bunch of always failing ENGINE APItb2023-07-211-5/+39
| | | | | | | | | | | | | | | This commit adds a few symbols under OPENSSL_NO_ENGINE. They will be used after the main ENGINE code is disabled in the next bump. The ecosystem is mostly prepared for dealing with a libcrypto compiled with OPENSSL_NO_ENGINE. There are a few stragglers like M2Crypto, dovecot and the latest apr-util release (fixed in their development branch). To avoid intrusive patching in these ports, we need to keep a bunch of ENGINE symbols around despite adding OPENSSL_NO_ENGINE. This of course meant patching some other ports, but that was way easier. ok jsing
* Move x509.h inclusion into alphabetical ordertb2023-04-181-3/+2
|
* Bring includes into canonical ordertb2023-04-181-8/+8
| | | | Requested by jsing
* Move some includes out of OPENSSL_NO_DEPRECATEDtb2023-04-181-3/+1
| | | | | | | | | | | | | Some headers were included conditionally on OPENSSL_NO_DEPRECATED in hopes that eventually the mess of everything includes everything will magically resolve itself. Of course everyone would end up building openssl with OPENSSL_NO_DEPRECATED over time... Right. Surprisingly, the ecosystem has come to rely on these implicit inclusions, so about two dozen ports would fail to build because of this. Patching this would be easy but really not worth the effort. ok jsing
* spelling fixes; from paul tagliamontejmc2022-12-261-2/+2
| | | | | | | i removed the arithmetics -> arithmetic changes, as i felt they were not clearly correct ok tb
* Remove mkerr.pl remnants from LibreSSLkn2022-07-121-5/+1
| | | | | | | This script is not used at all and files are edited by hand instead. Thus remove misleading comments incl. the obsolete script/config. Feedback OK jsing tb
* Partial port of EC_KEY_METHOD from OpenSSL 1.1.tb2019-01-191-1/+13
| | | | | | | This commit adds init/free, support for signing, setting and getting the method, engine support as well as extra data. from markus
* Add automatic threading initialization for libcrypto.bcook2018-11-111-6/+1
| | | | | | | | | | | | | | This implements automatic thread support initialization in libcrypto. This does not remove any functions from the ABI, but does turn them into no-ops. Stub implementations of pthread_mutex_(init|lock|unlock) are provided for ramdisks. This does not implement the new OpenSSL 1.1 thread API internally, keeping the original CRYTPO_lock / CRYPTO_add_lock functions for library locking. For -portable, crypto_lock.c can be reimplemented with OS-specific primitives as needed. ok beck@, tb@, looks sane guenther@
* Remove OpenSSL engine RSAX.doug2015-07-191-2/+1
| | | | | | | | | OpenSSL stopped building it last year and removed it this year. Based on OpenSSL commit c436e05bdc7f49985a750df64122c960240b3ae1. Also cranked major version in libcrypto, libssl and libtls. "fine with me" bcook@ miod@
* None of these need to include <openssl/rand.h>jsing2014-10-181-2/+1
|
* KNF.jsing2014-06-221-36/+41
|
* tags as requested by miod and teduderaadt2014-06-121-1/+1
|
* Abandon the auto-ENGINE /dev/crypto interface. VIA 3des cbc receivesderaadt2014-06-101-5/+0
| | | | | | | | | | | | | collateral damage. The syncronous nature of this mechanism has hampered performance for symmetric crypto relative to brute-force cpu. The assymetric crypto support never really materialized in drivers. So abandon the complexity. ok tedu beck mikeb some disagrement from djm but if he wants to test /dev/crypto ciphers he should do it without this this gigantic API in the way
* A few months back there was a big community fuss regarding direct-usederaadt2014-06-021-1/+0
| | | | | | | | | | | | of the intel RDRAND instruction. Consensus was RDRAND should probably only be used as an additional source of entropy in a mixer. Guess which library bends over backwards to provide easy access to RDRAND? Yep. Guess which applications are using this support? Not even one... but still, this is being placed as a trap for someone. Send this support straight to the abyss. ok kettenis
* Expand the OPENSSL_{GLOBAL,EXPORT,IMPORT,EXTERN} macros - this rids thejsing2014-05-221-4/+4
| | | | | | libssl tree from all uses of these defines. ok miod@
* Remove the GOST engine: It is not compiled or used and depends on thereyk2014-04-151-3/+0
| | | | | | | | "dynamic engine" feature that is not enabled in our build. People who need it can still pull it out of the Attic; if it is to have a Russian engine just because it's a Russian engine. OK deraadt@ beck@
* Remove the GMP engine: It was an experimental engine using libgmp asreyk2014-04-141-3/+0
| | | | | | | an alternative backend for BIGNUM calculations. It is PoC code that is not enabled in OpenSSL and probably not used by anymore. ok deraadt@
* Remove the CAPI engine: It is a backend for the Windows CryptoAPI andreyk2014-04-141-1/+0
| | | | | | could be maintained in an external package. "it should probably go" beck@
* Remove the nuron engine. The static engine is not standalone and thereyk2014-04-141-1/+0
| | | | FPGA-based device is long obsolete.
* Remove the nCipher CHIL engine. It is not standalone and depends onreyk2014-04-141-17/+0
| | | | external libraries that aren't covered by the same license.
* Cope with the removal of openssl/symhacks.hderaadt2014-04-131-1/+0
|
* Remove the AEP engine: it is not standalone and doesn't seem to bereyk2014-04-131-1/+0
| | | | | | | | | relevant anymore. OpenSSL should have a better way to include 3rd party engines: either completely and free or external. But including a wrapper for a non-free wrapper in the code base does not make much sense and could also be provided by the vendor. ok deraadt@
* Remove the Atalla engine: It is not standalone and depends on externalreyk2014-04-131-1/+0
| | | | | | | | | non-free libraries. OpenSSL should have a better way to include 3rd party engines: either completely free or external. But including a wrapper for a non-free wrapper in the code base does not make much sense and could also be provided by the vendor. ok deraadt@
* Remove the cswift engine: it is not standalone and we don't have thereyk2014-04-131-1/+0
| | | | | | | | | | | | | hardware. The vendor_defns/cswift.h does not specify a copyright and theoretically defaults to the OpenSSL license, but it also mentions that it includes parts that have been "clipped" from CryptoSwift's proprietary headers. This file should better include an explicit copyright statement or mention OpenSSL's library instead of the ambiguous "Attribution notice". ok deraadt@
* Remove the "sureware" engine:reyk2014-04-131-1/+0
| | | | | | | | | | | | The vendor_defns/sureware.h file by Baltimore Technologies Ltd. has a copyright that does not grant rights! Vendor files should either include a compatible license in the copyright statement or use OpenSSL's defaults, but adding a copyright statement without any terms is not acceptable. It should not have been included in the first place. ok deraadt@
* Remove the Broadcom ubsec engine:reyk2014-04-131-1/+0
| | | | | | | | | | | | | The vendor_defns/hw_ubsec.h file has a copyright that does not grant rights! Vendor files should either include a compatible license in the copyright statement or use OpenSSL's defaults, but adding a copyright statement without any terms is not acceptable. It should not have been included in the first place. (The ubsec(4) kernel driver is not affected by this change) ok deraadt@
* Remove the IBM 4758 engine: we don't have this hardware and it is anreyk2014-04-131-1/+0
| | | | | | old PCI accelerator that was EOL'ed in 2005. ok deraadt@
* resolve conflictsdjm2012-10-131-1/+9
|
* openssl-1.0.0e: resolve conflictsdjm2011-11-031-0/+3
|
* resolve conflicts, fix local changesdjm2010-10-011-13/+42
|
* AES-NI engine support for OpenSSL.thib2010-07-011-0/+1
| | | | | | | | | | This is code mostly picked up from upstream OpenSSL, or to be more exact a diff from David Woodhouse <dwmw2 at infradead dot org>. Remember to make includes before doing a build! no objections from djm@ OK deraadt@, reyk@ (AES is about 4.25x faster on his x201 now)
* update to openssl-0.9.8i; tested by several, especially krw@djm2009-01-051-0/+16
|
* resolve conflictsdjm2008-09-061-51/+107
|
* merge 0.9.7dmarkus2004-04-081-12/+15
|
* merge 0.9.7c; minor bugsfixes;markus2003-11-111-2/+6
| | | | | API addition: ERR_release_err_state_table [make includes before you build libssl/libcrypto]
* merge 0.9.7b with local changes; crank majors for libssl/libcryptomarkus2003-05-121-4/+9
|
* merge with 0.9.7-beta1markus2002-09-051-1/+1
|
* OpenSSL 0.9.7 stable 2002 05 08 mergebeck2002-05-151-167/+486
|
* openssl-engine-0.9.6 mergebeck2000-12-151-0/+398
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-27 08:59:22 +0000