in the x509 utility.

SSL_CTX and SSL, functions to set them and defaults if no values set.

yet.

Add a function X509_STORE_CTX_purpose_inherit() which implements the logic
of "inheriting" purpose and trust from a parent structure and using a default:
this will be used in the SSL code and possibly future S/MIME.

Partial documentation of the 'verify' utility. Still need to document how all
the extension checking works and the various error messages.

trust settings of the root CA.

After a few fixes it seems to work OK.

Still need to add support to SSL and S/MIME code though.

in a table. Doesn't do too much yet.

Make the -<digestname> options in 'x509' affect all relevant
options.

Change the name of the 'notrust' options to 'reject' as this
causes less confusion and is a better description of the
effect.

A few constification changes.

Extend the X509_PURPOSE structure to include shortnames for purposed and default
trust ids.

Still need some extendable trust checking code and integration with the SSL and
S/MIME code.

at present. However nothing enables it yet so this doesn't
matter :-)

Fix so EVP_PKEY_rset_*() check return codes.

New universal public key format.

Fix CRL+cert load problem in by_file.c

Make verify report errors when loading files or dirs

don't leak tons of memory.

Remove rc4-64 from ciphers since it doesn't exist...

Previously, the returned SSL_SESSION didn't have its reference count
incremented so the SSL_SESSION could be freed at any time causing
seg-faults if the pointer was subsequently used. Code that uses
SSL_get_session must now make a corresponding SSL_SESSION_free() call when
it is done to avoid memory leaks (or blocked up session caches).

Submitted By: Geoff Thorpe <geoff@eu.c2.net>

Fix to stop null being added to attributes.
Modify X509_LOOKUP, X509_INFO to handle auxiliary info.

add documentation for 'enc'.

and add an nseq manpage.

The info removal code was overcomplicated, and error-prone (references being wrongly decreased).  Fixed.

  1. Added code to the memory leak detecting code to give the user the
     possibility to add information, thereby forming a traceback.

  2. Make the memory leak detecting code multithread-safe.

The idea is that we're actually dealing with two separate critical
sections, one containing the hash tables with the information, the
other containing the current memory checking mode.  Those should not
be handled with the same lock, especially since their handling overlap.
Hence, the added second lock.

Some crypto applications are now being built on Unix, so they should on VMS as well.  Not by default, however.

works on Unix and MS-DOS/Windows.  It does not under VMS, so open it
as text.