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.

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.

recently. So comments including file names have been fixed, and copyright
notices brought up to "2001" at the same time.

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.

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.  :-)

error.  When checking like engine_add() is, those errors are actually
good, so remove them.

load the "external" built-in engines (those that require DSO).  This
makes linking with libdl or other dso libraries non-mandatory.

Change 'openssl engine' accordingly.

Change the engine header files so some declarations (that differed at
that!) aren't duplicated, and make sure engine_int.h includes
engine.h.  That way, there should be no way of missing the needed
info.

"symbols" including functions (of all prototypes( and variables. Whilst
casting any function type to another violates ANSI C (I believe), it is
a necessary evil in shared-library APIs. However, it is quite
conceivable that functions in general and data symbols could very well
be represented differently to each other on some systems, as Bodo said;

> Since the function/object distinction is a lot more likely to be
> important on real-life platforms supporting DSO *and* it can be quite
> easily done *and* it will silence compilers that don't like
> assignments from void pointers to function pointer variables, why
> not do it?

I agree. So this change splits the "dso_bind" handler in DSO_METHOD
into "dso_bind_var" and "dso_bind_func". Similarly the exported
function DSO_bind() has been split in two. I've also put together
changes for the various DSO_METHOD implementations, but so far only
DSO_dlfcn() has been tested. BTW: The prototype for dso_bind had been
a bit strange so I've taken the opportunity to change its shape (in
both variations).

Also, the README has been updated - particularly with a note about
using customised native name-translation for shared libraries (and that
you can't do it yet).

technique used is far from perfect and alternatives are welcome.
Basically if the translation flag is set, the string is not too
long, and there appears to be no path information in the string,
then it is converted to whatever the standard should be for the
DSO_METHOD in question, eg;
    blah --> libblah.so   on *nix, and
    blah --> blah.dll     on win32.

This change also introduces the DSO_ctrl() function that is used
by the name translation stuff.

the build process (an upcoming commit no doubt), and is very much *new*
code - what that means is that it compiles ok - usually. It certainly
doesn't mean it runs well or even properly yet. Please don't muck round
with this unless you're looking to help out and hunt bugs. :-)

Currently this code doesn't have any support for controlling the "load"
behaviour (eg. paths, filename translations, etc). That'll be handled
using DSO_ctrl() and various flags, once we work out a sensible set of
flags.

((void *)0), by have a 0 instead.

tolerated in certificates.

documentation to reflect the STACK_OF(CONF_VALUE) change to the CONF lib and
use ANSI typedefs for X509V3_EXT_I2D and X509V3_EXT_FREE.

-Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations
-Wnested-externs -Winline'' with EGCS 1.1.2+

Submitted by:
Reviewed by:
PR:

it is just a place holder for functionality to be added later. Its been added
now so the X509V3_EXT_METHOD structure shouldn't (hopefully) have to change
after the release.

without -debug option to mk1mf.pl. Change _export to is_export (_export is
a reserved word under VC++). Add yucky function prototype function pointer
casts. Sanitise the included files in crypto/x509v3.

Also changed ssleay.exe target to openssl.exe

to support CRL extensions.

GeneralizedTime. At several points PKIX specifies that GeneralizedTime can be
used but OpenSSL doesn't currently support it. This patch adds several files
and a bunch of functions.

Of interest is the ASN1_TIME structure and its related functions. At several
points certificates, CRLs et al specify that a time can be expressed as a
choice of UTCTime and GeneralizedTime. Currently OpenSSL interprets this
(wrongly) as UTCTime because GeneralizedTime isn't supported. The ASN1_TIME
stuff provides this functionality.

Still todo is to trace which cert and CRL points need an ASN1_TIME and modify
the utilities appropriately and of course fix all the bugs.

Note new OpenSSL copyright in the new file a_time.c. I didn't put it in
a_gentm.c because it is a minimally modified form a_utctm.c .

Since this adds new files and error codes you will need to do a 'make errors'
at the top level to add the new codes.