Age | Commit message (Collapse) | Author |
|
PR: 2613
Submitted by: Leena Heino
|
|
Submitted by: Paul Green <Paul.Green@stratus.com>
Reviewed by: steve
Improved PRNG seeding for VOS.
|
|
New functionality to allow default DRBG type to be set during compilation or during runtime.
|
|
the FIPS library to fail. Applications that want to set the FIPS rand
method can do so explicitly and presumably they know what they are doing...
|
|
|
|
|
|
Add static build support to openssl utility.
Add new "fips" option to Configure.
Make use of installed fipsld and fips_standalone_sha1
Initialise FIPS error callbacks, locking and DRBG.
Doesn't do anything much yet: no crypto is redirected to the FIPS module.
Doesn't completely build either but the openssl utility can enter FIPS mode:
which doesn't do anything much either.
|
|
|
|
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.
|
|
[from HEAD].
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: "Paul Smedley" <pauldespam@despamsmedley.id.au>
Approved by: steve@openssl.org
OS/2 fixes (excludes Makefile.shared patch for now).
|
|
Submitted by: "Green, Paul" <Paul.Green@stratus.com>
Approved by: steve@openssl.org
Fixes to --with-zlib-include and --with-zlib-lib and init PRNG for VOS.
|
|
|
|
|
|
.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
|
|
|
|
|
|
|
|
large FD: it's non-blocking mode anyway
|
|
|
|
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: 1312
Submitted by: Oliver Tappe <zooey@hirschkaefer.de>
Reviewed by: Ulf Moeller
|
|
|