- 02 12月, 2015 1 次提交
-
-
由 Rich Salz 提交于
Add CRYPTO_free_ex_index (for shared libraries) Unify and complete the documentation for all "ex_data" API's and objects. Replace xxx_get_ex_new_index functions with a macro. Added an exdata test. Renamed the ex_data internal datatypes. Reviewed-by: NMatt Caswell <matt@openssl.org>
-
- 05 11月, 2015 1 次提交
-
-
由 Dr. Stephen Henson 提交于
Rebuild error source files: the new mkerr.pl functionality will now pick up and translate static function names properly. Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 20 7月, 2015 1 次提交
-
-
由 Rich Salz 提交于
Removed ability to set ex_data impl at runtime. This removed these three functions: const CRYPTO_EX_DATA_IMPL *CRYPTO_get_ex_data_implementation(void); int CRYPTO_set_ex_data_implementation(const CRYPTO_EX_DATA_IMPL *i); int CRYPTO_ex_data_new_class(void); It is no longer possible to change the ex_data implementation at runtime. (Luckily those functions were never documented :) Also removed the ability to add new exdata "classes." We don't believe this received much (if any) use, since you can't add it to OpenSSL objects, and there are probably better (native) methods for developers to add their own extensible data, if they really need that. Replaced the internal hash table (of per-"class" stacks) with a simple indexed array. Reserved an index for "app" application. Each API used to take the lock twice; now it only locks once. Use local stack storage for function pointers, rather than malloc, if possible (i.e., number of ex_data items is under a dozen). Make CRYPTO_EX_DATA_FUNCS opaque/internal. Also fixes RT3710; index zero is reserved. Reviewed-by: NRichard Levitte <levitte@openssl.org>
-
- 22 1月, 2015 1 次提交
-
-
由 Matt Caswell 提交于
Reviewed-by: NTim Hudson <tjh@openssl.org>
-
- 20 5月, 2011 1 次提交
-
-
由 Dr. Stephen Henson 提交于
-
- 22 11月, 2006 1 次提交
-
-
由 Dr. Stephen Henson 提交于
-
- 13 4月, 2005 1 次提交
-
-
由 Dr. Stephen Henson 提交于
-
- 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.
-
- 20 2月, 2001 1 次提交
-
-
由 Richard Levitte 提交于
sure they are available in opensslconf.h, by giving them names starting with "OPENSSL_" to avoid conflicts with other packages and by making sure e_os2.h will cover all platform-specific cases together with opensslconf.h. I've checked fairly well that nothing breaks with this (apart from external software that will adapt if they have used something like NO_KRB5), but I can't guarantee it completely, so a review of this change would be a good thing.
-
- 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 :-)).
-
- 05 3月, 2000 1 次提交
-
-
由 Bodo Möller 提交于
-
- 24 4月, 1999 2 次提交
-
-
由 Dr. Stephen Henson 提交于
script, translates function codes better and doesn't need the K&R function prototypes to work (NB. the K&R prototypes can't be wiped just yet: they are still needed by the DEF generator...). I also ran the script with the -rewrite option to update all the header and source files.
-
由 Bodo Möller 提交于
Submitted by: Reviewed by: PR:
-
- 20 4月, 1999 1 次提交
-
-
由 Ulf Möller 提交于
-
- 21 12月, 1998 3 次提交
-
-
由 Ralf S. Engelschall 提交于
-
由 Ralf S. Engelschall 提交于
-
由 Ralf S. Engelschall 提交于
-