- 02 9月, 2001 1 次提交
-
-
由 Geoff Thorpe 提交于
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.
-
- 26 7月, 2001 1 次提交
-
-
由 Bodo Möller 提交于
-
- 19 6月, 2001 1 次提交
-
-
由 Dr. Stephen Henson 提交于
-
- 01 6月, 2001 2 次提交
-
-
由 Richard Levitte 提交于
-
由 Richard Levitte 提交于
links.
-
- 07 5月, 2001 1 次提交
-
-
由 Richard Levitte 提交于
like des_read_password and friends (backward compatibility functions using this new API are provided). The purpose is to remove prompting functions from the DES code section as well as provide for prompting through dialog boxes in a window system and the like.
-
- 20 2月, 2001 1 次提交
-
-
由 Richard Levitte 提交于
missed any. This compiles and runs on Linux, and external applications have no problems with it. The definite test will be to build this on VMS.
-
- 16 12月, 2000 1 次提交
-
-
由 Bodo Möller 提交于
-
- 27 10月, 2000 1 次提交
-
-
由 Richard Levitte 提交于
At the same time, add VMS support for Rijndael.
-
- 21 6月, 2000 1 次提交
-
-
由 Dr. Stephen Henson 提交于
Handle ASN1_SET_OF and PKCS12_STACK_OF using function casts in the same way as STACK_OF.
-
- 20 6月, 2000 1 次提交
-
-
由 Richard Levitte 提交于
Also, make sure empty slots of the dynamic lock stack are used. Actually, I'm not really sure this is the right thing to do, and may remove it, with an endlessly growing stack as result...
-
- 19 6月, 2000 2 次提交
-
-
由 Bodo Möller 提交于
-
由 Richard Levitte 提交于
insecure, so a static lock is added to isolate the sensitive parts. Also, to avoid one thread freeing a lock that is used by another, a reference counter is added.
-
- 18 6月, 2000 1 次提交
-
-
由 Richard Levitte 提交于
be needed in some ENGINE code, and might serve elsewhere as well. Note that it's implemented in such a way that the locking itself is done through the same CRYPTO_lock function as the static locks. WARNING: This is currently experimental and untested code (it will get tested soon, though :-)).
-
- 02 6月, 2000 1 次提交
-
-
由 Richard Levitte 提交于
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.
-
- 05 4月, 2000 1 次提交
-
-
由 Geoff Thorpe 提交于
variety of platforms. A few are missing, and they will be added in eventually, but as this is new stuff, it was better to not break lots of platforms in one go that we can't easily test. The changes to "Configure" should illustrate how to add support to other systems if you feel like having a go. NB: I'll add something shortly to allow you to add "dlfcn.h" support on those platforms that don't have (or need) a dlfcn.h header file. (The symbol for Configure will probably by "dlfcn_no_h"). Thanks to Richard Levitte, who is responsible for the dso_dl.c support, understanding the trickier aspects of the build process, and giving great feedback on everything else. [Don't use this stuff if you're easily offended by changes to the interface or behaviour - it's still work in progress.] PR:
-
- 20 12月, 1999 1 次提交
-
-
由 Andy Polyakov 提交于
-
- 12 11月, 1999 1 次提交
-
-
由 Richard Levitte 提交于
1. Added code to the memory leak detecting code to give the user the possibility to add information, thereby forming a traceback. 2. Make the memory leak detecting code multithread-safe. The idea is that we're actually dealing with two separate critical sections, one containing the hash tables with the information, the other containing the current memory checking mode. Those should not be handled with the same lock, especially since their handling overlap. Hence, the added second lock.
-
- 24 8月, 1999 1 次提交
-
-
由 Dr. Stephen Henson 提交于
DSA_METHOD to make it more consistent with RSA_METHOD.
-
- 22 7月, 1999 1 次提交
-
-
由 Bodo Möller 提交于
use new file buildinf.h instead.
-
- 19 6月, 1999 1 次提交
-
-
由 Bodo Möller 提交于
-
- 14 5月, 1999 2 次提交
-
-
由 Bodo Möller 提交于
thread-safe (where thread-safe counterparts are not available on all platforms), and don't memcpy to NULL-pointers Submitted by: Anonymous Reviewed by: Bodo Moeller Also, clean up htons vs. ntohs confusions.
-
由 Bodo Möller 提交于
Submitted by: Reviewed by: PR:
-
- 27 4月, 1999 2 次提交
-
-
由 Ulf Möller 提交于
-
由 Ulf Möller 提交于
-
- 24 4月, 1999 1 次提交
-
-
由 Bodo Möller 提交于
Submitted by: Reviewed by: PR:
-
- 20 4月, 1999 1 次提交
-
-
由 Ulf Möller 提交于
-
- 18 4月, 1999 1 次提交
-
-
由 Ben Laurie 提交于
-
- 21 12月, 1998 3 次提交
-
-
由 Ralf S. Engelschall 提交于
-
由 Ralf S. Engelschall 提交于
-
由 Ralf S. Engelschall 提交于
-