History log of /openssl/crypto/ex_data.c (Results 76 – 89 of 89)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 26188931 02-Sep-2001 Ben Laurie

Make MD functions take EVP_MD_CTX * instead of void *, add copy() function.


# 3a079997 01-Sep-2001 Geoff Thorpe

First step in fixing "ex_data" support. Warning: big commit log ...

Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety

First step in fixing "ex_data" support. Warning: big commit log ...

Currently, this change merely addresses where ex_data indexes are stored
and managed, and thus fixes the thread-safety issues that existed at that
level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
and per-class index counters - all such data is stored inside ex_data.c. So
rather than passing both STACK+counter to index-management ex_data
functions, a 'class_index' is instead passed to indicate the class (eg.
CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
and this is also thread-safe inside ex_data.c (though whether the caller
manages the return value in a thread-safe way is not addressed).

This does not change the "get/set" functions on individual "ex_data"
structures, and so thread-safety at that level isn't (yet) assured.
Likewise, the method of getting and storing per-class indexes has not
changed, so locking may still be required at the "caller" end but is
nonetheless thread-safe inside "ex_data"'s internal implementation.
Typically this occurs when code implements a new method of some kind and
stores its own per-class index in a global variable without locking the
setting and usage of that variable. If the code in question is likely to be
used in multiple threads, locking the setting and use of that index is
still up to the code in question. Possible fixes to this are being
sketched, but definitely require more major changes to the API itself than
this change undertakes.

The underlying implementation in ex_data.c has also been modularised so
that alternative "ex_data" implementations (that control all access to
state) can be plugged in. Eg. a loaded module can have its implementation
set to that of the application loaded it - the result being that
thread-safety and consistency of "ex_data" classes and indexes can be
maintained in the same place rather than the loaded module using its own
copy of ex_data support code and state.

Due to the centralisation of "state" with this change, cleanup of all
"ex_data" state can now be performed properly. Previously all allocation of
ex_data state was guaranteed to leak - and MemCheck_off() had been used to
avoid it flagging up the memory debugging. A new function has been added to
perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
command(s) have been changed to use this cleanup, as have the relevant test
programs. External application code may want to do so too - failure to
cleanup will not induce more memory leaking than was the case before, but
the memory debugging is not tricked into hiding it any more so it may
"appear" where it previously did not.

show more ...


Revision tags: OpenSSL-engine-0_9_6b, OpenSSL_0_9_6b, OpenSSL_0_9_6a, OpenSSL-engine-0_9_6a, OpenSSL-engine-0_9_6a-beta3, OpenSSL_0_9_6a-beta3, OpenSSL-engine-0_9_6a-beta2, OpenSSL_0_9_6a-beta2, OpenSSL-engine-0_9_6a-beta1, OpenSSL_0_9_6a-beta1
# cb38052b 18-Dec-2000 Bodo Möller

Comment correction.


# 3ac82faa 15-Dec-2000 Bodo Möller

Locking issues.


Revision tags: rsaref
# bbbc96a8 06-Nov-2000 Richard Levitte

Constification of CRYPTO_get_ex_data() needed for the sake of
RSA_get_ext_data().


Revision tags: BEFORE_engine
# 0ded1638 16-Oct-2000 Richard Levitte

CRYPTO_get_ex_new_index would never return an error.


Revision tags: OpenSSL_0_9_6-beta2, OpenSSL_0_9_6-beta1, OpenSSL_0_9_6, OpenSSL-engine-0_9_6, OpenSSL-engine-0_9_6-beta3, OpenSSL_0_9_6-beta3, OpenSSL-engine-0_9_6-beta2, OpenSSL-engine-0_9_6-beta1
# 26a3a48d 01-Jun-2000 Richard Levitte

There have been a number of complaints from a number of sources that names
like Malloc, Realloc and especially Free conflict with already existing names
on some operating systems or other pac

There have been a number of complaints from a number of sources that names
like Malloc, Realloc and especially Free conflict with already existing names
on some operating systems or other packages. That is reason enough to change
the names of the OpenSSL memory allocation macros to something that has a
better chance of being unique, like prepending them with OPENSSL_.

This change includes all the name changes needed throughout all C files.

show more ...


Revision tags: OpenSSL_0_9_5, OpenSSL_0_9_5a, OpenSSL_0_9_5a-beta2, OpenSSL_0_9_5a-beta1, OpenSSL_0_9_5beta2, OpenSSL_0_9_5beta1
# dd9d233e 23-Jan-2000 Dr. Stephen Henson

Tidy up CRYPTO_EX_DATA structures.


Revision tags: OpenSSL_0_9_4
# 49b81422 22-Jul-1999 Ulf Möller

Make the perl module compile and eliminate some of the warnings.
Still doesn't work (the destructor on BIO and SSL is called immediately
after creating the object. Why that??)


Revision tags: OpenSSL_0_9_3a, OpenSSL_0_9_3, OpenSSL_0_9_3beta2, OpenSSL_0_9_3beta1
# e84240d4 19-May-1999 Dr. Stephen Henson

New functions sk_set, sk_value and sk_num to replace existing macros: this is
to minimise the effects on existing code.


# ec577822 23-Apr-1999 Bodo Möller

Change #include filenames from <foo.h> to <openssl.h>.

Submitted by:
Reviewed by:
PR:


# 6b691a5c 19-Apr-1999 Ulf Möller

Change functions to ANSI C.


Revision tags: OpenSSL_0_9_2b, OpenSSL_0_9_1c, SSLeay_0_9_1b
# dfeab068 21-Dec-1998 Ralf S. Engelschall

Import of old SSLeay release: SSLeay 0.9.1b (unreleased)


Revision tags: SSLeay_0_9_0b
# 58964a49 21-Dec-1998 Ralf S. Engelschall

Import of old SSLeay release: SSLeay 0.9.0b


1234