during "make errors" and thus during "make update".

Fix lots of bugs that util/ck_errf.pl can detect automatically.
Various others of these are still left to fix; that's why
"make update" will complain loudly when run now.

the engine implementations need to include bn.h to manipulate bignums.

consolidated these prior to committing).

changes are the fallout). As this could break source code that doesn't
directly include headers for interfaces it uses, changes to recursive
includes are covered by the OPENSSL_NO_DEPRECATED symbol. It's better to
define this when building and using openssl, and then adapt code where
necessary - this is how to stay current. However the mechanism exists for
the lethargic.

operations no longer require two distinct BN_CTX structures. This may put
more "strain" on the current BN_CTX implementation (which has a fixed limit
to the number of variables it will hold), but so far this limit is not
triggered by any of the tests pass and I will be changing BN_CTX in the
near future to avoid this problem anyway.

This also changes the default RSA implementation code to use the BN_CTX in
favour of initialising some of its variables locally in each function.

PR: 780
Submitted by: Verdon Walker <VWalker@novell.com>
Reviewed by: Richard Levitte

override key-generation implementations by placing handlers in the methods
for DSA and DH. Also, parameter generation for DSA and DH is possible by
another new handler for each method.

ENGINEs implement it.

OpenSSL header files.

OPENSSL_NO_DYNAMIC_ENGINE and make sure that gets defined unless
shared library support has been specifically requested.

to be prefixed with e_ instead of hw_.  They aren't necessarely hardware
engines.  The files commited here are exact copies of the corresponding
hw_ files found in crypto/engine/.

Part of PR 75

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

not return immediately since that leaves a locked lock.

consistent with the rest of the AEP functions

CRYPTO_LOCK_RAND...

lets change our prefix to AEPHK_R_.  Otherwise, we get very mysterious
errors because we happen to redefine AEP_R_OK and AEP_R_GENERAL_ERROR.

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.