Submitted by:
Reviewed by:
PR: 285

ia5String correctly.
PR: 244

PR: 332

PR: 332

Typo in OCSP ASN1 module

PR: 329

PR: 163

boolean option in ASN1_TYPE.

Submitted by: Nils Larsch

the extreme ones special (or 'extreme', if you will :-)).

PR: 235

a year.

Identified by Goetz Babin-Ebell <babinebell@trustcenter.de>

other branches.

PR: 156

don't take an ENGINE* as parameter any more.
PR: 156

relates to SSL_CTX flags and the use of "external" session caching. The
existing flag, "SSL_SESS_CACHE_NO_INTERNAL_LOOKUP" remains but is
supplemented with a complimentary flag, "SSL_SESS_CACHE_NO_INTERNAL_STORE".
The bitwise OR of the two flags is also defined as
"SSL_SESS_CACHE_NO_INTERNAL" and is the flag that should be used by most
applications wanting to implement session caching *entirely* by its own
provided callbacks. As the documented behaviour contradicted actual
behaviour up until recently, and since that point behaviour has itself been
inconsistent anyway, this change should not introduce any compatibility
problems. I've adjusted the relevant documentation to elaborate about how
this works.

Kudos to "Nadav Har'El" <nyh@math.technion.ac.il> for diagnosing these
anomalies and testing this patch for correctness.

PR: 311

CertificateVerify for 4096 bit RSA signatures

RSAref data, pretend we don't care for OpenSSL's MD2 and MD5 structures or
implementation.
Remove all kinds of silly warning

apps.h.  For those, it's better to include apps.h after the system
headers where those symbols may be defined, since there's otherwise a
chance that the C compiler will barf when it sees something that looks
like this after expansion:

int VMS_strcasecmp((str1),(str2))(const char *, const char *);

PR: 314

'OpenSSL_0_9_7-stable'.

of libcrypto, then it is possible that when they are loaded they will share
the same static data as the loading application/library. This means it will
be too late to set memory/ERR/ex_data/[etc] callbacks, but entirely
unnecessary to try. This change puts a static variable in the core ENGINE
code (contained in libcrypto) and a function returning a pointer to it. If
the loaded ENGINE's return value from this function matches the loading
application/library's return value - they share static data. If they don't
match, the loaded ENGINE has its own copy of libcrypto's static data and so
the callbacks need to be set.

Also, although 0.9.7 hasn't been released yet, it's clear this will
introduce a binary incompatibility between dynamic ENGINEs built for 0.9.7
and 0.9.8 (though others probably exist already from EC_*** hooks and
what-not) - so the version control values are correspondingly bumped.