summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/crypto_init.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Provide crypto_cpu_caps_init() as a CPU capability detection entry point.jsing2024-10-171-3/+4
| | | | | | | This can be overridden on a per-architecture basis. The default version calls OPENSSL_cpuid_setup(), which will be eventually replaced/removed. ok joshua@ tb@
* Finish Hiding symbols in crypto.hbeck2024-04-101-1/+2
| | | | | | | | | | | | | crypto.h already had the symbols not hidden behind LIBRESSL_INTERNAL hidden - This now picks up the reset of them marking them as LCRYPTO_UNUSED, and removes the LIBRESSL_INTERNAL guard. These symbols will now be hidden, but if we use them inside the library in a namespaced build we will get a deprecation warning. use outside the library will be as with any other hidden symbol, so fine. ok tb@
* Hide public symbols in evp.hbeck2024-04-091-1/+5
| | | | | | largely mechanically done by the guentherizer 9000 ok tb@
* Move the OPENSSL_init() stub from o_init.c to crypto_init.ctb2024-03-191-1/+6
|
* Ditch another noop from OPENSSL_cleanup()tb2024-01-251-2/+1
|
* Remove calls to OpenSSL_add_all_{ciphers,digests}()tb2024-01-131-3/+1
|
* Stub out {OpenSSL,OPENSSL}_add*tb2024-01-131-1/+22
| | | | | | | | | | | These serve no purpose anymore (and really haven't for many years) but will have to be kept since there's a number of software that still uses them because many years ago they had to. Relocate the stubs to crypto_init.c since library initialization's what they were there for. ok jsing
* Garbage collect call to X509_TRUST_cleanup()tb2024-01-071-2/+1
| | | | Since x509_trs.c r1.33, this is a noop.
* Remove X509_PURPOSE_cleanup() call in OPENSSL_cleanup()tb2024-01-061-2/+1
| | | | | Since x509_purp.c r1.34 this is a noop since there is nothing to clean up anymore. Remove the last caller.
* Remove call to ASN1_STRING_TABLE_cleanup()tb2023-12-161-2/+1
| | | | | | | | In a few minutes, the string table will no longer have anything to clean up and ASN1_STRING_TABLE_cleanup() will push an error on the stack. So remove this pointless call in the still too complicated OPENSSL_cleanup(). ok jsing
* Unifdef OPENSSL_NO_ENGINE in libcryptotb2023-11-191-7/+1
| | | | | | | This is mechanical apart from a few manual edits to avoid doubled empty lines. ok jsing
* Hide symbols in crypto.hbeck2023-07-081-1/+3
| | | | ok jsing@
* Clean up dynamic tables in OPENSSL_cleanup()tb2023-07-021-1/+10
| | | | | | | | | This is not currently done in OpenSSL, but it looks more like something that was mised rather than desired behavior. There are some thread safety issues here, but those are rife in this codebase anyway (although I heard claims on some versions of this lib being "fully threadsafe"). no objection jsing
* Properly guard ENGINE usage with !OPENSSL_NO_ENGINEtb2023-06-191-1/+5
|
* Add RCS tagtb2023-05-081-0/+1
|
* Call CRYPTO_cleanup_all_ex_data() from OPENSSL_cleanup().jsing2023-03-111-0/+1
| | | | | | Issue reported by Graham Percival (@gperciva) ok tb@
* Prepare to provide OPENSSL_cleanup.jsing2022-09-031-4/+24
| | | | | | | | | | OPENSSL_cleanup() cleans up and deallocates memory in use by the library. There are a couple of use cases for this, primarily related to memory leak testing. This will not be called automatically in LibreSSL, which means that OpenSSL's OPENSSL_NO_INIT_ATEXIT is implied. If code wants to clean up then they need to explicitly call this themselves. ok tb@
* Correct lock initialisation for libcrypto.jsing2018-11-281-3/+2
| | | | | | | | | | | | The current crypto_lock_init() function is not called early enough, meaning that locks are already in use before it gets called. Worse, locks could be in use when they are then initialised. Furthermore, since functions like CRYPTO_lock() are public API, these could be called directly bypassing initialisation. Avoid these issues by using static initialisers. ok bcook@
* Add automatic threading initialization for libcrypto.bcook2018-11-111-0/+3
| | | | | | | | | | | | | | 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@
* correct funciton prototypebeck2018-03-191-3/+3
| | | | spotted by anton@
* Correct mistake of loading the default openssl.conf by default during autoinit.beck2018-03-191-4/+11
| | | | | | | | This brings in the OPENSSL_INIT_LOAD_CONFIG flag with the same semantics as OpenSSL. As a result, by default the openssl.conf file is not loaded during autoinit, which makes autoinit safe for pledge(stdio). ok jsing@
* Bring in compatibility for OpenSSL 1.1 style init functions.beck2018-03-171-0/+56
This adds OPENSSL_init_crypto and OPENSSL_init_ssl, as well thread safety modifications for the existing LibreSSL init functions. The initialization routines are called automatically by the normal entry points into the library, as in newer OpenSSL ok jsing@, nits by tb@ and deraadt@
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-03-19 14:53:30 +0000