RT2630 -- segfault for int overlow
RT2877 -- check return values in apps/rand
Update CHANGES file for previous "windows rand" changes.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Add -DBIO_DEBUG to --strict-warnings.
Remove comments about outdated debugging ifdef guards.
Remove md_rand ifdef guarding an assert; it doesn't seem used.
Remove the conf guards in conf_api since we use OPENSSL_assert, not assert.
For pkcs12 stuff put OPENSSL_ in front of the macro name.
Merge TLS_DEBUG into SSL_DEBUG.
Various things just turned on/off asserts, mainly for checking non-NULL
arguments, which is now removed: camellia, bn_ctx, crypto/modes.
Remove some old debug code, that basically just printed things to stderr:
DEBUG_PRINT_UNKNOWN_CIPHERSUITES, DEBUG_ZLIB, OPENSSL_RI_DEBUG,
RL_DEBUG, RSA_DEBUG, SCRYPT_DEBUG.
Remove OPENSSL_SSL_DEBUG_BROKEN_PROTOCOL.
Reviewed-by: Richard Levitte <levitte@openssl.org>
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: Rich Salz <rsalz@openssl.org>
Reviewed-by: Viktor 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: Viktor 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: Richard Levitte <levitte@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: Rich Salz <rsalz@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: Richard 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: Andy Polyakov <appro@openssl.org>
Reviewed-by: Tim 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 5be1ae28ef)
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.
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.
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.
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.
