Change all calls to low level digest routines in the library and
applications to use EVP. Add missing calls to HMAC_cleanup() and
don't assume HMAC_CTX can be copied using memcpy().

Note: this is almost identical to the patch submitted to openssl-dev
by Verdon Walker <VWalker@novell.com> except some redundant
EVP_add_digest_()/EVP_cleanup() calls were removed and some changes
made to avoid compiler warnings.

and make all files the depend on it include it without prefixing it
with openssl/.

This means that all Makefiles will have $(TOP) as one of the include
directories.

missed any.

This compiles and runs on Linux, and external applications have no
problems with it.  The definite test will be to build this on VMS.

sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.

I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.

supporting threads, which means that th assertion is supperbly
dangerous, so make sure it's not compiled under Win32, period.

it wants to stir the pool using ssleay_rand_add.  This fix provides the
possibility to call ssleay_rand_add inside a locked state by simply telling
it not to do any locking through a static variable.  This isn't the most
elegant way one could do this, but it does retain thread safety during the
stirring process.

rand_lcl.h

today.  Time to add extra info so the poor users know where to
go with their troubles.

They have nothing to do with the particular PRNG (md_rand.c).

variables are locked.

it's a good thing if ssleay_rand_status() would do the corresponding
lock and unlock as everyone else...

on Win32.

because this will drain the entropy pool.

instead of 'unsigned' counters.
Seed PRNG in MacOS/GetHTTPS.src/GetHTTPS.cpp.

Partially submitted by Yoram Meroz <yoram@mail.idrive.com>.

Slightly clarify the RAND_... documentation.

are not guaranteed to be unpredictable.

and re-enable seeding with more data than read from DEVRANDOM -- just
don't pretend it contains entropy.

returns int (1 = ok, 0 = not seeded). New function RAND_add() is the
same as RAND_seed() but takes an estimate of the entropy as an additional
argument.

don't try to detect fork()s by looking at getpid().
The reason is that threads sharing the same memory can have different
PIDs; it's inefficient to run RAND_seed each time a different thread
calls RAND_bytes.