of libcrypto, then it is possible that when they are loaded they will share
the same static data as the loading application/library. This means it will
be too late to set memory/ERR/ex_data/[etc] callbacks, but entirely
unnecessary to try. This change puts a static variable in the core ENGINE
code (contained in libcrypto) and a function returning a pointer to it. If
the loaded ENGINE's return value from this function matches the loading
application/library's return value - they share static data. If they don't
match, the loaded ENGINE has its own copy of libcrypto's static data and so
the callbacks need to be set.
Also, although 0.9.7 hasn't been released yet, it's clear this will
introduce a binary incompatibility between dynamic ENGINEs built for 0.9.7
and 0.9.8 (though others probably exist already from EC_*** hooks and
what-not) - so the version control values are correspondingly bumped.
normal 'structural' case (ENGINE_init() satisfies this in the less normal
'functional' case). This change provides such a function.
- Correct some "read" locks that should actually be "write" locks.
- make update.
automatic load of dynamic engines. Change the iterator to try to load
the requested engine dynamically. The environment variable
OPENSSL_ENGINES can be used to override the internal default directory
where one can expect to find dynamically loadable engines.
Note: The changes in step 11 have all been made by Geoff Thorpe.
Credit where credit is due.
automatic load of dynamic engines. Add functionality to the dynamic
engine to handle engine directories and loading from those. This
is currently NOT compatible with the use of LD_LIBRARY_PATH and
similar environment variables.
Note: The changes in step 11 have all been made by Geoff Thorpe.
Credit where credit is due.
engine with something they claim is better. I have nothing to compare to,
and I assume they know what they're talking about. The interesting part with
this one is that it's loaded by default on OpenBSD systems.
This change was originally introduced in OpenBSD's tracking of OpenSSL.
Additional changes:
- use EC_GROUP_get_degree() in apps/req.c
- add ECDSA and ECDH to apps/speed.c
- adds support for EC curves over binary fields to ECDSA
- new function EC_KEY_up_ref() in crypto/ec/ec_key.c
- reorganize crypto/ecdsa/ecdsatest.c
- add engine support for ECDH
- fix a few bugs in ECDSA engine support
Submitted by: Douglas Stebila <douglas.stebila@sun.com>
Changes marked "(CHATS)" were sponsored by the Defense Advanced
Research Projects Agency (DARPA) and Air Force Research Laboratory,
Air Force Materiel Command, USAF, under agreement number
F30602-01-2-0537.
(the same keys can be used for ECC schemes other than ECDSA)
and add some new options.
Similarly, use string "EC PARAMETERS" instead of "ECDSA PARAMETERS"
in 'PEM' format.
Fix ec_asn1.c (take into account the desired conversion form).
'make update'.
Submitted by: Nils Larsch
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.
