des_old.h redefines crypt:
#define crypt(b,s)\
DES_crypt((b),(s))
This scheme leads to failure, if header files with the OS's true definition
of crypt() are processed _after_ des_old.h was processed. This is e.g. the
case on HP-UX with unistd.h.
As evp.h now again includes des.h (which includes des_old.h), this problem
only came up after this modification.
Solution: move header files (indirectly) including e_os.h before the header
files (indirectly) including evp.h.
Submitted by:
Reviewed by:
PR:
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
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.
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.
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.
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.
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.
setting stack (actually, array) values in ex_data. So only increment the
global counters if the underlying CRYPTO_get_ex_new_index() call succeeds.
This change doesn't make "ex_data" right (see the comment at the head of
ex_data.c to know why), but at least makes the source code marginally less
frustrating.
with arbitrary arguments instead of just a string.
- Change the key loaders to take a UI_METHOD instead of a callback
function pointer. NOTE: this breaks binary compatibility with
earlier versions of OpenSSL [engine].
- Addapt the nCipher code for these new conditions and add a card
insertion callback.
passwords that were given to the key loading functions were completely
ignored, at least in the ncipher code, and then we made the assumption
that the callback wanted a prompt as user argument.
All that is now changed, and the application author is forced to give
a callback function of type pem_callback_cb and possibly an argument
for it, just as for all other functions that want to generate password
prompting.
NOTE: this change creates binary and source incompatibilities with
previous versions of OpenSSL [engine]. It's worth it this time, to
get it right (or at least better and with a chance that it'll work).
few statements equivalent to "ENGINE_add(ENGINE_openssl())" etc. The inner
call to ENGINE_openssl() (as with other functions like it) orphans a
structural reference count. Second, the ENGINE_cleanup() function also
needs to clean up the functional reference counts held internally as the
list of "defaults" (ie. as used when RSA_new() requires an appropriate
ENGINE reference). So ENGINE_clear_defaults() was created and is called
from within ENGINE_cleanup(). Third, some of the existing code was
logically broken in its treatment of reference counts and locking (my
fault), so the necessary bits have been restructured and tidied up.
To test this stuff, compiling with ENGINE_REF_COUNT_DEBUG will cause every
reference count change (both structural and functional) to log a message to
'stderr'. Using with "openssl engine" for example shows this in action
quite well as the 'engine' sub-command cleans up after itself properly.
Also replaced some spaces with tabs.
* "ex_data" - a CRYPTO_EX_DATA structure in the ENGINE structure itself
that allows an ENGINE to store its own information there rather than in
global variables. It follows the declarations and implementations used
in RSA code, for better or worse. However there's a problem when storing
state with ENGINEs because, unlike related structure types in OpenSSL,
there is no ENGINE-vs-ENGINE_METHOD separation. Because of what ENGINE
is, it has method pointers as its structure elements ... which leads
to;
* ENGINE_FLAGS_BY_ID_COPY - if an ENGINE should not be used just as a
reference to an "implementation" (eg. to get to a hardware device), but
should also be able to maintain state, then this flag can be set by the
ENGINE implementation. The result is that any call to ENGINE_by_id()
will not result in the existing ENGINE being returned (with its
structural reference count incremented) but instead a new copy of the
ENGINE will be returned that can maintain its own state independantly of
any other copies returned in the past or future. Eg. key-generation
might involve a series of ENGINE-specific control commands to set
algorithms, sizes, module-keys, ids, ACLs, etc. A final command could
generate the key. An ENGINE doing this would *have* to declare
ENGINE_FLAGS_BY_ID_COPY so that the state of that process can be
maintained "per-handle" and unaffected by other code having a reference
to the same ENGINE structure.
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.
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.
and make all files the depend on it include it without prefixing it
with openssl/.
This means that all Makefiles will have $(TOP) as one of the include
directories.
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.
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. :-)
situation where they've initialised the ENGINE, loaded keys (which are then
linked to that ENGINE), and performed other checks (such as verifying
certificate chains etc). At that point, if the application goes
multi-threaded or multi-process it creates problems for any ENGINE
implementations that are either not thread/process safe or that perform
optimally when they do not have to perform locking and other contention
management tasks at "run-time".
This defines a new ENGINE_ctrl() command that can be supported by engines
at their discretion. If ENGINE_ctrl(..., ENGINE_CTRL_HUP,...) returns an
error then the caller should check if the *_R_COMMAND_NOT_IMPLEMENTED error
reason was set - it may just be that the engine doesn't support or need the
HUP command, or it could be that the attempted reinitialisation failed. A
crude alternative is to ignore the return value from ENGINE_ctrl() (and
clear any errors with ERR_clear_error()) and perform a test operation
immediately after the "HUP". Very crude indeed.
ENGINEs can support this command to close and reopen connections, files,
handles, or whatever as an alternative to run-time locking when such things
would otherwise be needed. In such a case, it's advisable for the engine
implementations to support locking by default but disable it after the
arrival of a HUP command, or any other indication by the application that
locking is not required. NB: This command exists to allow an ENGINE to
reinitialise without the ENGINE's functional reference count having to sink
down to zero and back up - which is what is normally required for the
finish() and init() handlers to get invoked. It would also be a bad idea
for engine_lib to catch this command itself and interpret it by calling the
engine's init() and finish() handlers directly, because reinitialisation
may need special handling on a case-by-case basis that is distinct from a
finish/init pair - eg. calling a finish() handler may invalidate the state
stored inside individual keys that have already loaded for this engine.
