- Sep 05, 2001
-
-
Bodo Möller authored
-
Bodo Möller authored
as the functions were only introduced a couple of days ago. Some '*)' apparently should be '+)' as the changes do not apply to the 0.9.6 bugfix branch.
-
Geoff Thorpe authored
-
Geoff Thorpe authored
error strings - the destroy handler functions unload the error strings so any pending error state referring to them will not attempt to reference them after the ENGINE has been destroyed.
-
Geoff Thorpe authored
being enabled or disabled (respectively) for operation. Additionally, each ENGINE has a constructor function where it can do more 'structural' level intialisations such as loading error strings, creating "ex_data" indices, etc. This change introduces a handler function that gives an ENGINE a corresponding opportunity to cleanup when the ENGINE is being destroyed. It also adds the "get/set" API functions that control this "destroy" handler function in an ENGINE.
-
Geoff Thorpe authored
-
Bodo Möller authored
-
Bodo Möller authored
-
Bodo Möller authored
-
Geoff Thorpe authored
-
Geoff Thorpe authored
declaration and implementation had not. So a recent update recreated the original definition in libeay.num ... this corrects it and changes the "dh" code to the "up_ref" variant.
-
Bodo Möller authored
defined. (Preprocessor symbols such as _POSIX_C_SOURCE or _XOPEN_SOURCE are supposed to disable anything not allowed by the respective specification; I'm not sure why 'strdup' would be considered an outlaw though.)
-
Ulf Möller authored
-
Ulf Möller authored
-
Ulf Möller authored
-
- Sep 04, 2001
-
-
Geoff Thorpe authored
measure (including info and instructions on "dynamic" ENGINEs).
-
Ulf Möller authored
Submitted by: "Brian Havard" <brianh@kheldar.apana.org.au>
-
Geoff Thorpe authored
locking callbacks to pass to the loaded library (in addition to the existing mem, ex_data, and err callbacks). Also change the default implementation of the "bind_engine" function to apply those callbacks, ie. the IMPLEMENT_DYNAMIC_BIND_FN macro.
-
Geoff Thorpe authored
recent changes. Also, do the same change to the DSO_up() function.
-
Bodo Möller authored
-
Bodo Möller authored
always load its strings because they might have been unloaded since the 'init' flag was deleted. But build_SYS_str_reasons() can use an 'init' flag.
-
Bodo Möller authored
-
Bodo Möller authored
(here: X509_STORE_CTX_init())
-
Bodo Möller authored
-
Bodo Möller authored
-
- Sep 03, 2001
-
-
Geoff Thorpe authored
declare their own error strings so that they can be more easily compiled as external shared-libraries if desired. Also, each implementation has been given canonical "dynamic" support at the base of each file and is only built if the ENGINE_DYNAMIC_SUPPORT symbol is defined. Also, use "void" prototypes rather than empty prototypes in engine_int.h. This does not yet; (i) remove error strings when unloading, (ii) remove the redundant ENGINE_R_*** codes (though ENGINE_F_*** codes have gone), or (iii) provide any instructions on how to build shared-library ENGINEs or use them. All are on their way.
-
Geoff Thorpe authored
implementations to be loaded from self-contained shared-libraries. It also provides (in engine.h) definitions and macros to help implement a self-contained ENGINE. Version control is handled in a way whereby the loader or loadee can veto the load depending on any objections it has with each other's declared interface level. The way this is currently implemented assumes a veto will only take place when one side notices the other's interface level is too *old*. If the other side is newer, it should be assumed the newer version knows better whether to veto the load or not. Version checking (like other "dynamic" settings) can be controlled using the "dynamic" ENGINE's control commands. Also, the semantics for the loading allow a shared-library ENGINE implementation to handle differing interface levels on the fly (eg. loading secondary shared-libraries depending on the versions required). Code will be added soon to the existing ENGINEs to illustrate how they can be built as external libraries rather than building statically into libcrypto. NB: Applications wanting to support "dynamic"-loadable ENGINEs will need to add support for ENGINE "control commands". See apps/engine.c for an example of this, and use "apps/openssl engine -vvvv" to test or experiment.
-
Geoff Thorpe authored
-
Geoff Thorpe authored
"ERR_load_strings" function.
-
Geoff Thorpe authored
-
Bodo Möller authored
[DR]SA_up => [DR]SA_up_ref
-
Bodo Möller authored
(by using new BN_pseudo_rand_range function)
-
Bodo Möller authored
is a bad idea if OPENSSL_OPENBSD_DEV_CRYPTO is not defined
-
- Sep 02, 2001
-
-
Geoff Thorpe authored
Henson). Also, reverse a previous change that used an implicit function pointer cast rather than an explicit data pointer cast in the STACK cleanup code.
-
Ben Laurie authored
-
- Sep 01, 2001
-
-
Geoff Thorpe authored
-
Geoff Thorpe authored
See the commit log message for that for more information. NB: X509_STORE_CTX's use of "ex_data" support was actually misimplemented (initialisation by "memset" won't/can't/doesn't work). This fixes that but requires that X509_STORE_CTX_init() be able to handle errors - so its prototype has been changed to return 'int' rather than 'void'. All uses of that function throughout the source code have been tracked down and adjusted.
-
Geoff Thorpe authored
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.
-
Geoff Thorpe authored
-
Ulf Möller authored
-