if $(EXHEADER) is empty.

Notified by many, solution suggested by Carson Gaspar <carson@taltos.org>

performing AES encryption in hardware, as well as one accessing
hardware RNG. As you surely imagine this engine access this
extended instruction set. Well, only AES for the moment, support
for RNG is to be added later on...
PR: 889
Submitted by: Michal Ludvig <michal@logix.cz>

Obtained from: http://www.logix.cz/michal/devel/padlock/

the Makefiles. NB: this commit is probably going to generate a huge posting
and it is highly uninteresting to read.

This is part of a large change submitted by Markus Friedl <markus@openbsd.org>

Submitted by: Thierry Lelegard <thierry.lelegard@canal-plus.fr>

PR: 461

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.

don't build any "built-in" engines in that directory any more, except
fo the cryptodev one.

give it.
For 0.9.7 and up, that means util/domd needs to remove those double
dashes from the argument list when gcc is used to find the
dependencies.

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>

(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

handled properly.
Part of PR 75

Gittens.

Submitted by: Nils Larsch <nla@trustcenter.de>

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.

automatically.

libeay.num got tweaked so the old des symbols would retain their
positions.

Initial ENGINE config module, docs to follow.

Fix buffer overrun errors in OPENSSL_conf().

ENGING_TABLE mechanism. The necessary hooks from crypto/evp/ to use this
will be committed shortly.

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.

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.