This gets BN_.*free:
    BN_BLINDING_free BN_CTX_free BN_FLG_FREE BN_GENCB_free
    BN_MONT_CTX_free BN_RECP_CTX_free BN_clear_free BN_free BUF_MEM_free

Also fix a call to DSA_SIG_free to ccgost engine and remove some #ifdef'd
dead code in engines/e_ubsec.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Following ANSI C rules, remove the casts from calls to
OPENSSL_malloc and OPENSSL_realloc.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Start ensuring all OpenSSL "free" routines allow NULL, and remove
any if check before calling them.
This gets DH_free, DSA_free, RSA_free
Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

Add functions to return the "bits of security" for various public key
algorithms. Based on SP800-57.

PR: 287

Ensure EVP_CipherInit() uses the correct encode/decode parameter if
enc == -1

[Reported by Markus Friedl <markus@openbsd.org>]

Fix typo in dh_lib.c (use of DSAerr instead of DHerr).

Make {RSA,DSA,DH}_new_method obtain and release an ENGINE
functional reference in all cases.

ENGINE surgery. DH, DSA, RAND, and RSA now use *both* "method" and ENGINE
pointers to manage their hooking with ENGINE. Previously their use of
"method" pointers was replaced by use of ENGINE references. See
crypto/engine/README for details.

Also, remove the ENGINE iterations from evp_test - even when the
cipher/digest code is committed in, this functionality would require a
different set of API calls.

declaration and implementation had not. So a recent update recreated the
original definition in libeay.num ... this corrects it and changes the "dh"
code to the "up_ref" variant.

See the commit log message for that for more information.

NB: X509_STORE_CTX's use of "ex_data" support was actually misimplemented
(initialisation by "memset" won't/can't/doesn't work). This fixes that but
requires that X509_STORE_CTX_init() be able to handle errors - so its
prototype has been changed to return 'int' rather than 'void'. All uses of
that function throughout the source code have been tracked down and
adjusted.

dependant code has to directly increment the "references" value of each
such structure using the corresponding lock. Apart from code duplication,
this provided no "REF_CHECK/REF_PRINT" checking and violated
encapsulation.

setting stack (actually, array) values in ex_data. So only increment the
global counters if the underlying CRYPTO_get_ex_new_index() call succeeds.
This change doesn't make "ex_data" right (see the comment at the head of
ex_data.c to know why), but at least makes the source code marginally less
frustrating.

circumstances.

count of the ENGINE is x is not NULL since it will be freed
in {RSA,DSA,DH}_free().

ENGINE code does not return a default, set an error.

the initialisation and cleanup of "ex_data" elements to before an init()
handler and after a finish() handler respectively.

At the same time, add VMS support for Rijndael.

like Malloc, Realloc and especially Free conflict with already existing names
on some operating systems or other packages.  That is reason enough to change
the names of the OpenSSL memory allocation macros to something that has a
better chance of being unique, like prepending them with OPENSSL_.

This change includes all the name changes needed throughout all C files.

with RSA_METHOD (the **_get_default_methods do set the default value if
it's not set). However, the code had some duplication and was a bit
conter-intuitive.

New -pkcs12 option to CA.pl.
Document CA.pl script.
Initialise and free up the extra DH fields
(nothing uses them yet though).

Tidy up CRYPTO_EX_DATA structures.

DSA_METHOD to make it more consistent with RSA_METHOD.

Submitted by:
Reviewed by:
PR:

DSA_free(): this was causing crashes when for example an attempt was made
to handle a (currently) unsupported DH public key. Also X509_PUBKEY_set()i
wasn't checking errors from d2i_PublicKey().

1. The already released version was 0.9.1c and not 0.9.1b

2. The next release should be 0.9.2 and not 0.9.1d, because
   first the changes are already too large, second we should avoid any more
   0.9.1x confusions and third, the Apache version semantics of
   VERSION.REVISION.PATCHLEVEL for the version string is reasonable (and here
   .2 is already just a patchlevel and not major change).
tVS: ----------------------------------------------------------------------