| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
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@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
| |
|
|
| |
spotted by anton@
|
| |
|
|
|
|
|
|
| |
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@
|
|
|
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@
|
