Since there was some functions added in libeay.num, it means things
are going to move in libeay.num in the OpenSSL-engine-0_9_6-stable
branch and in the main trunk.

to create a symbol table).

Sun patches such as 109147-06 probably fix this problem,
but we can easily avoid it.

Fix bug in copy_email() which would not
find emailAddress at start of subject name.

We need this to find out if the bignum failures on Irix and Alpha are
caused by new 0.9.7 code or just aren't triggered in the 0.9.6 test suite.

handlers were previously getting called before (and after, respectively)
the "ex_data" structures - this meant init() had very little that it
could initialise, and finish() had very little it could cleanup.

Stop PKCS7_verify() core dumping with unknown public
key algorithms and leaking if the signature verify
fails.

'OpenSSL_0_9_6-stable'.

like to use libtool, but not automake.

Let's investigate that further, or leave the question open for now.

or serial number.

prototype hack. This unfortunately means that
every ASN1_*_END construct cannot have a
trailing ;

change the way ASN1 modules are exported.

Still needs a bit of work for example the hack which a
dummy function prototype to avoid compilers warning about
multiple ;s.

an SSL_CTX's session cache, it is necessary to compare the ssl_version at
the same time (a conflict is defined, courtesy of SSL_SESSION_cmp(), as a
matching id/id_length pair and a matching ssl_version). However, the
SSL_SESSION that will result from the current negotiation does not
necessarily have the same ssl version as the "SSL_METHOD" in use by the
SSL_CTX - part of the work in a handshake is to agree on an ssl version!

This is fixed by having the check function accept an SSL pointer rather
than the SSL_CTX it belongs to.

[Thanks to Lutz for illuminating the full extent of my stupidity]

Define the right macro for Linux and other GNU-based systems to get a correct declaration of strdup()

really see why we need to define these function pointers with MS_FAR
if it's not done cosistently everywhere.

If we decide to support MS_FAR modifiers, it's better to have the
named something more unique for OpenSSL and to define them in e_os2.h.

Define the OPENSSL_NO_* macros as NO_* macros for the sake of applications thathaven't yet been changed

to include (but the OpenSSL_0_9_6-stable branche still has
inconsistencies)