- 02 8月, 2002 1 次提交
-
-
由 Richard Levitte 提交于
-
- 21 6月, 2002 1 次提交
-
-
由 Geoff Thorpe 提交于
pointers passed to them whenever necessary. Otherwise it is possible the caller may have overwritten (or deallocated) the original string data when a later ENGINE operation tries to use the stored values. Submitted by: Götz Babin-Ebell <babinebell@trustcenter.de> Reviewed by: Geoff Thorpe PR: 98
-
- 08 2月, 2002 2 次提交
-
-
由 Richard Levitte 提交于
make them ubsec-specific in the ubsec implementation.
-
由 Richard Levitte 提交于
automatically.
-
- 12 12月, 2001 1 次提交
-
-
由 Richard Levitte 提交于
<sram@broadcom.com> with the following comment: [...] We have implemented failover (ie, if for some reason that the hardware fails, the implementation detects this failure and performs this operation as if no hardware is present, ie, in software) for sometime now and have tested it here with our hardware. [...] This change was cc:ed to exports@crypto.com
-
- 26 9月, 2001 1 次提交
-
-
由 Geoff Thorpe 提交于
ENGINE_TABLE-based stuff - as described in crypto/engine/README. Associated miscellaneous changes; - the previous cipher/digest hooks that hardwired directly to EVP's OBJ_NAME-based storage have been backed out. New cipher/digest support has been constructed and will be committed shortly. - each implementation defines its own ENGINE_load_<name> function now. - the "openssl" ENGINE isn't needed or loaded any more. - core (not algorithm or class specific) ENGINE code has been split into multiple files to increase readability and decrease linker bloat. - ENGINE_cpy() has been removed as it wasn't really a good idea in the first place and now, because of registration issues, can't be meaningfully defined any more. - BN_MOD_EXP[_CRT] support is removed as per the README. - a bug in enginetest.c has been fixed. NB: This commit almost certainly breaks compilation until subsequent changes are committed.
-
- 15 9月, 2001 1 次提交
-
-
由 Geoff Thorpe 提交于
recently. So comments including file names have been fixed, and copyright notices brought up to "2001" at the same time.
-
- 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. :-)
-