dynamic_ctrl() didn't have exactly the same prototype as defined by
ENGINE_CTRL_FUNC_PTR.

If dynamically-loadable ENGINEs are linked against a shared-library version
of libcrypto, then it is possible that when they are loaded they will share
the same static data as the loading app

If dynamically-loadable ENGINEs are linked against a shared-library version
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.

show more ...

Step 11b of move of engines: Time to make the changes to support
automatic load of dynamic engines. Add functionality to the dynamic
engine to handle engine directories and loading from thos

Step 11b of move of engines: Time to make the changes to support
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.

show more ...

Make sure any ENGINE control commands make local copies of string
pointers passed to them whenever necessary. Otherwise it is possible the
caller may have overwritten (or deallocated) the ori

Make sure any ENGINE control commands make local copies of string
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

show more ...

Cut "ENGINE_ID" to the more concise "ID".

When the "dynamic" ENGINE loads another ENGINE from a shared-library, it
essentially overwrites itself with the new ENGINE, with the exception of
reference counts, ex_data structures, and oth

When the "dynamic" ENGINE loads another ENGINE from a shared-library, it
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.

show more ...

After loading a dynamic engine, reset the command definitions to the
empty set. This prevents engines that do not set the command
definitions themselves to inherit the ones from "dynamic", w

After loading a dynamic engine, reset the command definitions to the
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.

show more ...

This change replaces the ENGINE's underlying mechanics with the new
ENGINE_TABLE-based stuff - as described in crypto/engine/README.

Associated miscellaneous changes;
- the previous

This change replaces the ENGINE's underlying mechanics with the new
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.

show more ...

Some of the ENGINE file names were changed for 8.3 filename uniqueness
recently. So comments including file names have been fixed, and copyright
notices brought up to "2001" at the same time.

make engine file names unique in 8.3