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.
This change adds some new functionality to the ENGINE code and API to
make it possible for ENGINEs to describe and implement their own control
commands that can be interrogated and used by calling applications at
run-time. The source code includes numerous comments explaining how it all
works and some of the finer details. But basically, an ENGINE will normally
declare an array of ENGINE_CMD_DEFN entries in its ENGINE - and the various
new ENGINE_CTRL_*** command types take care of iterating through this list
of definitions, converting command numbers to names, command names to
numbers, getting descriptions, getting input flags, etc. These
administrative commands are handled directly in the base ENGINE code rather
than in each ENGINE's ctrl() handler, unless they specify the
ENGINE_FLAGS_MANUAL_CMD_CTRL flag (ie. if they're doing something clever or
dynamic with the command definitions).
There is also a new function, ENGINE_cmd_is_executable(), that will
determine if an ENGINE control command is of an "executable" type that
can be used in another new function, ENGINE_ctrl_cmd_string(). If not, the
control command is not supposed to be exposed out to user/config level
access - eg. it could involve the exchange of binary data, returning
results to calling code, etc etc. If the command is executable then
ENGINE_ctrl_cmd_string() can be called using a name/arg string pair. The
control command's input flags will be used to determine necessary
conversions before the control command is called, and commands of this
form will always return zero or one (failure or success, respectively).
This is set up so that arbitrary applications can support control commands
in a consistent way so that tweaking particular ENGINE behaviour is
specific to the ENGINE and the host environment, and independant of the
application or OpenSSL.
Some code demonstrating this stuff in action will applied shortly to the
various ENGINE implementations, as well as "openssl engine" support for
executing arbitrary control commands before and/or after initialising
various ENGINEs.
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.
Previously RAND_get_rand_method was returning a non-const pointer, but it
should be const. As with all other such cases, METHOD pointers are stored and
returned as "const". The only methods one should be able to alter are methods
"local" to the relevant code, in which case a non-const handle to the methods
should already exist.
This change has been forced by the constifying of the ENGINE code (before
which RAND_METHOD was the only method pointer in an ENGINE structure that was
not constant).
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.
Previous changes permanently removed the commented-out old code for where
it was possible to create and use an ENGINE statically, and this code gets
rid of the ENGINE_FLAGS_MALLOCED flag that supported the distinction with
dynamically allocated ENGINEs. It also moves the area for ENGINE_FLAGS_***
values from engine_int.h to engine.h - because it should be possible to
declare ENGINEs just from declarations in exported headers.
* Constify the get/set functions, and add some that functions were missing.
* Add a new 'ENGINE_cpy()' function that will produce a new ENGINE based
copied from an original (except for the references, ie. the new copy will
be like an ENGINE returned from 'ENGINE_new()' - a structural reference).
* Removed the "null parameter" checking in the get/set functions - it is
legitimate to set NULL values as a way of *changing* an ENGINE (ie.
removing a handler that previously existed). Also, passing a NULL pointer
for an ENGINE is obviously wrong for these functions, so don't bother
checking for it. The result is a number of error codes and strings could
be removed.
without releasing a lock. This is the same fix as applied to
OpenSSL-engine-0_9_6-stable, minus the ENGINE_ctrl() change - the HEAD
already had that fixed.
des_encrypt() and des_encrypt() defined on some systems (Solaris and
Unixware and maybe others), we rename des_encrypt() to des_encrypt1().
This should have very little impact on external software unless
someone has written a mode of DES, since that's all des_encrypt() is
meant for.
the 'ca' utility. This can now be extensively
customised in the configuration file and handles
multibyte strings and extensions properly.
This is required when extensions copying from
certificate requests is supported: the user
must be able to view the extensions before
allowing a certificate to be issued.
