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

depend on the environment, like the presence of the OpenBSD crypto
device or of Kerberos, do not change the dependencies within OpenSSL.

them to one that won't get exported.

"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.