The use of the uninitialized buffer in the RNG has no real security
benefits and is only a nuisance when using memory sanitizers.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

This was done by the following
        find . -name '*.[ch]' | /tmp/pl
where /tmp/pl is the following three-line script:
        print unless $. == 1 && m@/\* .*\.[ch] \*/@;
        close ARGV if eof; # Close file to reset $.

And then some hand-editing of other files.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

Provide backwards-compatiblity for functions, macros and include
files if OPENSSL_API_COMPAT is either not defined or defined less
than the version number of the release in which the feature was
deprecated.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

The rand code can aquire locks and then attempt crypto operations. This
can end up in a deadlock if we are using an async engine, because control
returns back to the user code whilst still holding the lock. We need to
force synchronous operation for these sections of code.
Reviewed-by: NRich Salz <rsalz@openssl.org>

All instances of SSLeay (any combination of case) were replaced with
the case-equivalent OpenSSL.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Especially since after the #ifdef cleanups this is not useful.
Reviewed-by: NMatt Caswell <matt@openssl.org>

The justification for RAND_pseudo_bytes is somewhat dubious, and the reality
is that it is frequently being misused. RAND_bytes and RAND_pseudo_bytes in
the default implementation both end up calling ssleay_rand_bytes. Both may
return -1 in an error condition. If there is insufficient entropy then
both will return 0, but RAND_bytes will additionally add an error to the
error queue. They both return 1 on success.
Therefore the fundamental difference between the two is that one will add an
error to the error queue with insufficient entory whilst the other will not.
Frequently there are constructions of this form:

if(RAND_pseudo_bytes(...) <= 1)
	goto err;

In the above form insufficient entropy is treated as an error anyway, so
RAND_bytes is probably the better form to use.

This form is also seen:
if(!RAND_pseudo_bytes(...))
	goto err;

This is technically not correct at all since a -1 return value is
incorrectly handled - but this form will also treat insufficient entropy as
an error.

Within libssl it is required that you have correctly seeded your entropy
pool and so there seems little benefit in using RAND_pseudo_bytes.
Similarly in libcrypto many operations also require a correctly seeded
entropy pool and so in most interesting cases you would be better off
using RAND_bytes anyway. There is a significant risk of RAND_pseudo_bytes
being incorrectly used in scenarios where security can be compromised by
insufficient entropy.

If you are not using the default implementation, then most engines use the
same function to implement RAND_bytes and RAND_pseudo_bytes in any case.

Given its misuse, limited benefit, and potential to compromise security,
RAND_pseudo_bytes has been deprecated.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Rename OPENSSL_SYSNAME_xxx to OPENSSL_SYS_xxx
Remove MS_STATIC; it's a relic from platforms <32 bits.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NTim Hudson <tjh@openssl.org>

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

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

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

Treat a zero length passed to ssleay_rand_add a no op: the existing logic
zeroes the md value which is very bad. OpenSSL itself never does this
internally and the actual call doesn't make sense as it would be passing
zero bytes of entropy.

Thanks to Marcus Meissner <meissner@suse.de> for reporting this bug.
(cherry picked from commit 5be1ae28ef3c4bdec95b94f14e0e939157be550a)

If available rdrand is used as an additional entropy source for the
PRNG and for additional input in FIPS mode.

The function gettimeofday() is not supported on all platforms. Use
more portable versions. Adapted from FIPS code.

Make sure crypto.h is included first in any affected files.

definition. Remove stale function references from fips.h

to EVP any more.

Move locking #define into fips.h.

Set FIPS locking callbacks at same time as OpenSSL locking callbacks.

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

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.

builds work properly...

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.

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.

CRYPTO_get_idptr_callback(), CRYPTO_thread_idptr() for a 'void *' type
thread ID, since the 'unsigned long' type of the existing thread ID
does not always work well.

PR: 359

compilers may complain.

I have tried to convert 'len' type variable declarations to unsigned as a
means to address these warnings when appropriate, but when in doubt I have
used casts in the comparisons instead. The better solution (that would get
us all lynched by API users) would be to go through and convert all the
function prototypes and structure definitions to use unsigned variables
except when signed is necessary. The proliferation of (signed) "int" for
strictly non-negative uses is unfortunate.

I've covered all the memset()s I felt safe modifying, but may have missed some.