- 06 9月, 2001 1 次提交
-
-
由 Geoff Thorpe 提交于
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.
-
- 04 9月, 2001 1 次提交
-
-
由 Geoff Thorpe 提交于
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.
-
- 01 6月, 2001 1 次提交
-
-
由 Richard Levitte 提交于
-
- 26 4月, 2001 1 次提交
-
-
由 Richard Levitte 提交于
appropriate code if any of them is defined.
-
- 19 4月, 2001 2 次提交
-
-
由 Geoff Thorpe 提交于
This change adds some basic control commands to the existing ENGINEs (except the software 'openssl' engine). All these engines currently load shared-libraries for hardware APIs, so they've all been given "SO_PATH" commands that will configure the chosen ENGINE to load its shared library from the given path. Eg. by calling; ENGINE_ctrl_cmd_string(e, "SO_PATH", <path>, 0). The nCipher 'chil' ENGINE has also had "FORK_CHECK" and "THREAD_LOCKING" commands added so these settings could be handled via application-level configuration rather than in application source code. Changes to "openssl engine" to test and examine these control commands will be made shortly. It will also provide the necessary tips to application programs wanting to support these dynamic control commands.
-
由 Geoff Thorpe 提交于
The existing ENGINEs (including the default 'openssl' software engine) were static, declared inside the source file for each engine implementation. The reason this was not going boom was that all the ENGINEs had reference counts that never hit zero (once linked into the internal list, each would always have at least 1 lasting structural reference). To fix this so it will stay standing when an "unload" function is added to match ENGINE_load_builtin_engines(), the "constructor" functions for each ENGINE implementation have been changed to dynamically allocate and construct their own ENGINEs using API functions. The other benefit of this is that no ENGINE implementation has to include the internal "engine_int.h" header file any more.
-
- 18 4月, 2001 2 次提交
-
-
由 Geoff Thorpe 提交于
ENGINE handler functions should take the ENGINE structure as a parameter - this is because ENGINE structures can be copied, and like other structure/method setups in OpenSSL, it should be possible for init(), finish(), ctrl(), etc to adjust state inside the ENGINE structures rather than globally. This commit includes the dependant changes in the ENGINE implementations.
-
由 Geoff Thorpe 提交于
-
- 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.
-
- 28 12月, 2000 1 次提交
-
-
由 Dr. Stephen Henson 提交于
functions and signed/unsigned mismatch. This will of course change if some of the unused functions suddenly get used...
-
- 15 12月, 2000 1 次提交
-
-
由 Geoff Thorpe 提交于
BCM5805 and BCM5820 units. So far I've merely taken a skim over the code and changed a few things from their original contributed source (de-shadowing variables, removing variables from the header, and re-constifying some functions to remove warnings). If this gives compilation problems on any system, please let me know. We will hopefully know for sure whether this actually functions on a system with the relevant hardware in a day or two. :-)
-