Add "init" command to control ENGINE
initialization.
Call ENGINE_finish on initialized ENGINEs on exit.
Reorder shutdown in apps.c: modules should be shut
down first.
Add test private key loader to openssl ENGINE: this
just loads a private key in PEM format.
Fix print format for dh length parameter.
Add "init" command to control ENGINE
initialization.
Call ENGINE_finish on initialized ENGINEs on exit.
Reorder shutdown in apps.c: modules should be shut
down first.
Add test private key loader to openssl ENGINE: this
just loads a private key in PEM format.
Fix print format for dh length parameter.
to the list using dynamic_path. This stops ENGINEs which
don't supply any default algorithms being automatically
freed (because they have no references) and allows them
to be accessed by id.
Alternative dynamic loading behaviour can be achieved by
issuing the dynamic ENGINE ctrls separately in the config file.
to the list using dynamic_path. This stops ENGINEs which
don't supply any default algorithms being automatically
freed (because they have no references) and allows them
to be accessed by id.
Alternative dynamic loading behaviour can be achieved by
issuing the dynamic ENGINE ctrls separately in the config file.
that were never part of the engine framework.
The aep and sureware implementations are taken directly from 0.9.6c
[engine] and have been modified to fit the newer engine framework and
to be possible to build shared libraries of.
The aep implementation has gone through quite a bunch of tests and is
cleaned up (there were some misunderstandings in it about how to use
locks).
The sureware hasn't been tested at all in this incarnation and is
basically a quick hack to get it to compile properly.
<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
essentially overwrites itself with the new ENGINE, with the exception of
reference counts, ex_data structures, and other 'admin' elements. However
if the new ENGINE doesn't populate certain elements, there's the risk of
the "dynamic" ENGINE's elements showing through - the "cmd_defns" were just
one of the possibilities. This implements a more comprehensive cleanup.
empty set. This prevents engines that do not set the command
definitions themselves to inherit the ones from "dynamic", which would
otherwise be very confusing.
it to be defined on all platforms whether or not it is of any practical
use on them. This also resolves linker problems on "special" platforms,
such as win32.
of the stack, and the (void *) type used in the underlying sk_***
functions. However, declaring a STACK_OF(type) where type is a *function*
type implicitly involves casts between function pointers and data pointers.
That's a no-no. This changes the ENGINE_CLEANUP handling to use a regular
data type in the stack.
ENGINE redevelopment. The idea had been that "-1" could be used as a
special "ask me later" 'nid' rather than specifying supported cipher and
digest 'nid's up front. However the idea turned out to be pretty broken.
testing. Because of the recent changes (see crypto/engine/README), the
"openssl" ENGINE is no longer needed nor is it loaded automatically or by
ENGINE_load_builtin_engines(). So a explicit ENGINE_load_openssl() call is
required by applications or a modification to eng_all.c before this ENGINE
will be used. This change will send output to stderr as/when its
implementations are used.
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.
digest support, are on their way. Rather than having gigantic commit log
messages and/or CHANGES entries, this change to the README will serve as an
outline of what it all is and how it all works.
in "types.h" so that very few headers will need to include engine.h,
generally only C files using API functions will need it (reducing
the header dependencies quite a lot).
(Some platforms need _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED to get
the declaration, but on other platforms _XOPEN_SOURCE disables
the strdup declaration in <string.h>.)
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.
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.
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.)
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.
