need a whole new PRNG for FIPS).

1. avoid use of ERR_peek().

2. If compiling with FIPS use small FIPS EVP and disable ENGINE

Submitted by: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
Reviewed by: steve

Fix OpenBSD compilation failure.

PR: 2296

Submitted by: James Baker <jbaker@tableausoftware.com> et al.

Workaround for slow Heap32Next on some versions of Windows.

Submitted by: Kevin Regan <k.regan@f5.com>

Clear stat structure if -DPURIFY is set to avoid problems on some
platforms which include unitialised fields.

Submitted by: Robin Seggelmann <seggelmann@fh-muenster.de>
Reviewed by: steve@openssl.org

ECDH negotiation bug.

.DLL, in particular static build. The issue has been discussed in RT#1230
and later on openssl-dev, and mutually exclusive approaches were suggested.
This completes compromise solution suggested in RT#1230.
PR: 1230

knock-on work than expected - they've been extracted into a patch
series that can be completed elsewhere, or in a different branch,
before merging back to HEAD.

Submitted by: "Alon Bar-Lev" <alon.barlev@gmail.com>
Approved by: steve@openssl.org

Fix some size_t issues.

builds work properly...

Submitted by: David North

deprecate the original (numeric-only) scheme, and replace with the
CRYPTO_THREADID object. This hides the platform-specifics and should reduce
the possibility for programming errors (where failing to explicitly check
both thread ID forms could create subtle, platform-specific bugs).

Thanks to Bodo, for invaluable review and feedback.

version some time soon.

Submitted by: Ben Laurie <ben@links.org>

complaint related to the PRNG: with PURIFY policy don't feed uninitialized
memory into the PRNG.

Submitted by: Bodo Moeller <bmoeller@openssl.org> :-)

to 'unsigned long' (ie. odd platforms/compilers), so a pointer-typed
version was added but it required portable code to check *both* modes to
determine equality. This commit maintains the availability of both thread
ID types, but deprecates the type-specific accessor APIs that invoke the
callbacks - instead a single type-independent API is used.  This simplifies
software that calls into this interface, and should also make it less
error-prone - as forgetting to call and compare *both* thread ID accessors
could have led to hard-to-debug/infrequent bugs (that might only affect
certain platforms or thread implementations). As the CHANGES note says,
there were corresponding deprecations and replacements in the
thread-related functions for BN_BLINDING and ERR too.

Submitted by: Guenter Knauf <eflash@gmx.net>

Note: the RAND_bytes() manual page says:
 RAND_bytes() puts num cryptographically strong pseudo-random bytes into buf.
It does not talk about using the previous contents of buf so we are working
as documented.

code checking tools.
PR: 1499