summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/crypto_init.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* 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-04-26 09:41:49 +0000