History log of /openssl/crypto/ex_data.c (Results 26 – 50 of 89)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 1aedc35f 01-May-2019 Matt Caswell

Instead of global data store it in an OPENSSL_CTX

Various core and property related code files used global data. We should
store all of that in an OPENSSL_CTX instead.

Reviewed-

Instead of global data store it in an OPENSSL_CTX

Various core and property related code files used global data. We should
store all of that in an OPENSSL_CTX instead.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8857)

show more ...


# 23dc8feb 06-Apr-2019 FdaSilvaYY

Coverity: fix two minor NPD issues.
Found by Coverity.

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@or

Coverity: fix two minor NPD issues.
Found by Coverity.

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8274)

show more ...


# e17f5b6a 08-Feb-2019 Richard Levitte

Add CRYPTO_alloc_ex_data()

This allows allocation of items at indexes that were created after the
CRYPTO_EX_DATA variable was initialized, using the exact same method
that was used t

Add CRYPTO_alloc_ex_data()

This allows allocation of items at indexes that were created after the
CRYPTO_EX_DATA variable was initialized, using the exact same method
that was used then.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8225)

show more ...


# 0e9725bc 06-Dec-2018 Richard Levitte

Following the license change, modify the boilerplates in crypto/

[skip ci]

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7827)


# eb2b9892 20-Apr-2018 Bernd Edlinger

Ensure the thread keys are always allocated in the same order

Fixes: #5899

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Mer

Ensure the thread keys are always allocated in the same order

Fixes: #5899

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5911)

show more ...


# 6738bf14 13-Feb-2018 Matt Caswell

Update copyright year

Reviewed-by: Richard Levitte <levitte@openssl.org>


# 63ab5ea1 16-Jan-2018 Benjamin Kaduk

Revert the crypto "global lock" implementation

Conceptually, this is a squashed version of:

Revert "Address feedback"

This reverts commit 75551e07bd2339dfea06ef1d31

Revert the crypto "global lock" implementation

Conceptually, this is a squashed version of:

Revert "Address feedback"

This reverts commit 75551e07bd2339dfea06ef1d31d69929e13a4495.

and

Revert "Add CRYPTO_thread_glock_new"

This reverts commit ed6b2c7938ec6f07b15745d4183afc276e74c6dd.

But there were some intervening commits that made neither revert apply
cleanly, so instead do it all as one shot.

The crypto global locks were an attempt to cope with the awkward
POSIX semantics for pthread_atfork(); its documentation (the "RATIONALE"
section) indicates that the expected usage is to have the prefork handler
lock all "global" locks, and the parent and child handlers release those
locks, to ensure that forking happens with a consistent (lock) state.
However, the set of functions available in the child process is limited
to async-signal-safe functions, and pthread_mutex_unlock() is not on
the list of async-signal-safe functions! The only synchronization
primitives that are async-signal-safe are the semaphore primitives,
which are not really appropriate for general-purpose usage.

However, the state consistency problem that the global locks were
attempting to solve is not actually a serious problem, particularly for
OpenSSL. That is, we can consider four cases of forking application
that might use OpenSSL:

(1) Single-threaded, does not call into OpenSSL in the child (e.g.,
the child calls exec() immediately)

For this class of process, no locking is needed at all, since there is
only ever a single thread of execution and the only reentrancy is due to
signal handlers (which are themselves limited to async-signal-safe
operation and should not be doing much work at all).

(2) Single-threaded, calls into OpenSSL after fork()

The application must ensure that it does not fork() with an unexpected
lock held (that is, one that would get unlocked in the parent but
accidentally remain locked in the child and cause deadlock). Since
OpenSSL does not expose any of its internal locks to the application
and the application is single-threaded, the OpenSSL internal locks
will be unlocked for the fork(), and the state will be consistent.
(OpenSSL will need to reseed its PRNG in the child, but that is
an orthogonal issue.) If the application makes use of locks from
libcrypto, proper handling for those locks is the responsibility of
the application, as for any other locking primitive that is available
for application programming.

(3) Multi-threaded, does not call into OpenSSL after fork()

As for (1), the OpenSSL state is only relevant in the parent, so
no particular fork()-related handling is needed. The internal locks
are relevant, but there is no interaction with the child to consider.

(4) Multi-threaded, calls into OpenSSL after fork()

This is the case where the pthread_atfork() hooks to ensure that all
global locks are in a known state across fork() would come into play,
per the above discussion. However, these "calls into OpenSSL after
fork()" are still subject to the restriction to async-signal-safe
functions. Since OpenSSL uses all sorts of locking and libc functions
that are not on the list of safe functions (e.g., malloc()), this
case is not currently usable and is unlikely to ever be usable,
independently of the locking situation. So, there is no need to
go through contortions to attempt to support this case in the one small
area of locking interaction with fork().

In light of the above analysis (thanks @davidben and @achernya), go
back to the simpler implementation that does not need to distinguish
"library-global" locks or to have complicated atfork handling for locks.

Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5089)

show more ...


# f32b0abe 28-Sep-2017 Pauli

Remove unnecessary #include <openssl/lhash.h> directives.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4431)


# ed6b2c79 29-Aug-2017 Rich Salz

Add CRYPTO_thread_glock_new

Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/4294)


# 1ee21259 26-Apr-2017 Todd Short

Fix ex_data and session_dup issues

Code was added in commit b3c31a65 that overwrote the last ex_data value
using CRYPTO_dup_ex_data() causing a memory leak, and potentially
confusing

Fix ex_data and session_dup issues

Code was added in commit b3c31a65 that overwrote the last ex_data value
using CRYPTO_dup_ex_data() causing a memory leak, and potentially
confusing the ex_data dup() callback.

In ssl_session_dup(), fix error handling (properly reference and up-ref
shared data) and new-up the ex_data before calling CRYPTO_dup_ex_data();
all other structures that dup ex_data have the destination ex_data new'd
before the dup.

Fix up some of the ex_data documentation.

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3323)

show more ...


# b3c31a65 19-Mar-2017 Bernd Edlinger

Fix the error handling in CRYPTO_dup_ex_data.
Fix a strict aliasing issue in ui_dup_method_data.
Add test coverage for CRYPTO_dup_ex_data, use OPENSSL_assert.

Reviewed-by: Rich Salz

Fix the error handling in CRYPTO_dup_ex_data.
Fix a strict aliasing issue in ui_dup_method_data.
Add test coverage for CRYPTO_dup_ex_data, use OPENSSL_assert.

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2988)

show more ...


Revision tags: OpenSSL_1_1_0e
# 83b4049a 01-Feb-2017 Bernd Edlinger

Combined patch against master branch for the following issues:

Fixed a memory leak in ASN1_digest and ASN1_item_digest.
Reworked error handling in asn1_item_embed_new.
Fixed error ha

Combined patch against master branch for the following issues:

Fixed a memory leak in ASN1_digest and ASN1_item_digest.
Reworked error handling in asn1_item_embed_new.
Fixed error handling in int_ctx_new and EVP_PKEY_CTX_dup.
Fixed a memory leak in CRYPTO_free_ex_data.
Reworked error handing in x509_name_ex_d2i, x509_name_encode and x509_name_canon.
Check for null pointer in tls_process_cert_verify.

Fixes #2103 #2104 #2105 #2109 #2111 #2115

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2342)

show more ...


Revision tags: OpenSSL_1_0_2k, OpenSSL_1_1_0d, OpenSSL-fips-2_0_15, OpenSSL-fips-2_0_14, OpenSSL_1_1_0c, OpenSSL_1_0_2j, OpenSSL_1_1_0b, OpenSSL_1_0_1u, OpenSSL_1_0_2i, OpenSSL_1_1_0a
# 135648bc 05-Sep-2016 Matt Caswell

Fix mem leaks during auto-deinit

Certain functions are automatically called during auto-deinit in order
to deallocate resources. However, if we have never entered a function which
ma

Fix mem leaks during auto-deinit

Certain functions are automatically called during auto-deinit in order
to deallocate resources. However, if we have never entered a function which
marks lib crypto as inited then they never get called. This can happen if
the user only ever makes use of a small sub-set of functions that don't hit
the auto-init code.

This commit ensures all such resources deallocated by these functions also
init libcrypto when they are initially allocated.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Ben Laurie <ben@openssl.org>

show more ...


Revision tags: OpenSSL_1_1_0, OpenSSL_1_1_0-pre6
# 3c853776 31-Jul-2016 Richard J. Moore

Const the ex data stuff too to fix warnings

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>


# c2e4e5d2 19-Jul-2016 Richard Levitte

Change all our uses of CRYPTO_THREAD_run_once to use RUN_ONCE instead

That way, we have a way to check if the init function was successful
or not.

Reviewed-by: Kurt Roeckx <kurt

Change all our uses of CRYPTO_THREAD_run_once to use RUN_ONCE instead

That way, we have a way to check if the init function was successful
or not.

Reviewed-by: Kurt Roeckx <kurt@openssl.org>

show more ...


Revision tags: OpenSSL-fips-2_0_13
# aa6bb135 17-May-2016 Rich Salz

Copyright consolidation 05/10

Reviewed-by: Richard Levitte <levitte@openssl.org>


# 5c4328f0 15-May-2016 Viktor Dukhovni

Fold threads.h into crypto.h making API public

Document thread-safe lock creation

Reviewed-by: Richard Levitte <levitte@openssl.org>


Revision tags: OpenSSL_1_0_1t, OpenSSL_1_0_2h, OpenSSL_1_1_0-pre5
# 1ee7b8b9 14-Apr-2016 Matt Caswell

Fix ex_data locks issue

Travis identified a problem with freeing the ex_data locks which wasn't
quite right in ff2344052. Trying to fix it identified a further problem:
the ex_data l

Fix ex_data locks issue

Travis identified a problem with freeing the ex_data locks which wasn't
quite right in ff2344052. Trying to fix it identified a further problem:
the ex_data locks are cleaned up by OPENSSL_cleanup(), which is called
explicitly by CRYPTO_mem_leaks(), but then later the BIO passed to
CRYPTO_mem_leaks() is freed. An attempt is then made to use the ex_data
lock already freed.

Reviewed-by: Tim Hudson <tjh@openssl.org>

show more ...


Revision tags: OpenSSL_1_1_0-pre4
# ff234405 11-Mar-2016 Matt Caswell

Ensure all locks are properly cleaned up

Some locks were not being properly cleaned up during close down.

Reviewed-by: Richard Levitte <levitte@openssl.org>


# b3599dbb 12-Apr-2016 Matt Caswell

Rename int_*() functions to *_int()

There is a preference for suffixes to indicate that a function is internal
rather than prefixes. Note: the suffix is only required to disambiguate

Rename int_*() functions to *_int()

There is a preference for suffixes to indicate that a function is internal
rather than prefixes. Note: the suffix is only required to disambiguate
internal functions and public symbols with the same name (but different
case)

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

show more ...


# 342c21cd 06-Apr-2016 Matt Caswell

Rename lots of *_intern or *_internal function to int_*

There was a lot of naming inconsistency, so we try and standardise on
one form.

Reviewed-by: Tim Hudson <tjh@openssl.org>

Rename lots of *_intern or *_internal function to int_*

There was a lot of naming inconsistency, so we try and standardise on
one form.

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

show more ...


# a5e3ac13 04-Apr-2016 Matt Caswell

Deprecate CRYPTO_cleanup_all_ex_data() and make it a no-op

CRYPTO_cleanup_all_ex_data() should not be called expicitly - we should
leave auto-deinit to clean this up instead.

Re

Deprecate CRYPTO_cleanup_all_ex_data() and make it a no-op

CRYPTO_cleanup_all_ex_data() should not be called expicitly - we should
leave auto-deinit to clean this up instead.

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

show more ...


# de705824 14-Mar-2016 FdaSilvaYY

Fix error code

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>


# e7c8cafa 13-Mar-2016 Richard Levitte

Change an function macro for ERR match the function it's used in.

Reviewed-by: Kurt Roeckx <kurt@openssl.org>


# 8cab4e9b 12-Mar-2016 Emilia Kasper

Fix memory leak in library deinit

ENGINE_cleanup calls CRYPTO_free_ex_data and therefore,
CRYPTO_cleanup_all_ex_data - which cleans up the method pointers - must
run after ENGINE_cle

Fix memory leak in library deinit

ENGINE_cleanup calls CRYPTO_free_ex_data and therefore,
CRYPTO_cleanup_all_ex_data - which cleans up the method pointers - must
run after ENGINE_cleanup.

Additionally, don't needlessly initialize the EX_CALLBACKS stack during
e.g. CRYPTO_free_ex_data. The only time this is actually needed is when
reserving the first ex data index. Specifically, since sk_num returns -1
on NULL input, the rest of the code already handles a NULL method stack
correctly.

Reviewed-by: Rich Salz <rsalz@openssl.org>

show more ...


1234