here could creates non-uniformity since very short fetches of 0 would
be excluded. blocks of 0 are just as random as any other data, including
blocks of 4 4 4.. This is a misguided attempt to identify errors from the
entropy churn/gather code doesn't make sense, errors don't happen.
ok bcook
use fallback mechanims if unsuccessful.
The design of Linux getrandom is broken. It has an
uninitialized phase coupled with blocking behaviour, which
is unacceptable from within a library at boot time without
possible recovery.
ok deraadt@ jsing@
In the event of a failure in _rs_allocate for rsx, we still have a reference to
freed memory for rs on return. Not a huge deal since we subsequently abort in
_rs_init, but it looks strange on its own.
ok deraadt@
For Windows, we are simply using calloc, which has two annoyances:
the memory has more permissions than needed by default, and it comes
from the process heap, which looks like a memory leak since this memory
is rightfully never freed.
This switches _rs_alloc on Windows to use VirtualAlloc, which restricts the
memory to READ|WRITE and keeps the memory out of the process heap.
ok deraadt@
Work around this particular case by reseeding whenever pid=1, but as guenther@
notes, directly calling clone(2), and then forking to match another pid,
provides other ways to bypass new process detection on Linux.
Hopefully at some point Linux implements something like MAP_INHERIT_ZERO, and
does not invent a corresponding mechanism to subvert it.
Noted by Sebastian Krahmer and the opmsg team.
See http://stealth.openwall.net/crypto/randup.c for a test program.
ok beck@
in asn1 and x509 code, all dealing with an ASN1_TIME. This brings the parsing
together in one function that converts into a struct tm. While we are at it this
also brings us into conformance with RFC 5280 for times allowed in an X509 cert,
as OpenSSL is very liberal with what it allows.
input and fixes from deraadt@ jsing@ guethther@ and others.
ok krw@, guenther@, jsing@
MD4 should have been removed a long time ago. Also, RFC 6150 moved it to
historic in 2011. Rides the major crank from removing SHA-0.
Discussed with many including beck@, millert@, djm@, sthen@
ok jsing@, input + ok bcook@
cpu's specific hardware capabilities users of libcrypto might be interested
in, as an integer value. This deprecates the existing OPENSSL_ia32cap()
macro and the OPENSSL_ia32cap_loc() function (which returns the pointer so
that you can mess with stuff you shouldn't mess with).
Interpreting the value returned by OPENSSL_cpu_caps() is, of course,
machine-dependent.
Minor version bump for libcrypto.
ok beck@ jsing@
OpenSSL stopped building it last year and removed it this year.
Based on OpenSSL commit c436e05bdc.
Also cranked major version in libcrypto, libssl and libtls.
"fine with me" bcook@ miod@
We do not build, test or ship any dynamic engines, so we can remove the dynamic
engine loader as well. This leaves a stub initialization function in its place.
ok beck@, reyk@, miod@
This only provides the sysctl wrapper in glibc, which we do not use and is not available in other libc implementations for Linux. Thanks to ncopa from github.
The issetugid() API is supposed to make a strong promise where "0
means it is safe to look at the environment". Way back in the past
someone on the OpenSSL team responded to the environment access danger
by creating a wrapper called OPENSSL_issetugid, and went to use it a
number of places. However, by default on systems lacking true
issetugid(), OPENSSL_issetugid returns 0. 0 indicating safely. False
safety. Which means OPENSSL_issetugid() fails to make any sort of
promise about safety, in fact it is just the opposite.
Can you believe the OpenSSL team?
This nastiness was noticed over the years, however noone could gain traction
and get it fixed in OpenSSL. Also see a paragraph about this in
http://www.tedunangst.com/flak/post/worst-common-denominator-programming
ok jsing
routines on hppa, the cause for sha512-parisc subtly misbehaving has been
found: despite having fallback pa1.1 code when running on a 32-bit cpu, the
shift constants used in the sigma computations in sha512 are >= 32 and are
silently truncated to 5 bits by the assembler, so there is no chance of
getting this code to work on a non-pa2.0 processor.
However, the pa1.1 fallback code for sha256 is safe, as it never attempts to
shift by more than 31, so reenable it again.
regress tests but causes tls ciphersuite using sha386 to fail; found the
hard way by henning@.
I can't see anything wrong in the generated assembly code yet, but building
a libcrypto with no assembler code but sha512_block_data_order() is enough
to trigger Henning's issue, so the bug lies there.
No ABI change; ok deraadt@
instead of disk. OpenSSL didn't provide a built-in API from loading
certificates in a chroot'ed process that doesn't have direct access to
the files. X509_STORE_load_mem() provides a new backend that will be
used by libssl and libtls to implement such privsep-friendly
functionality.
Adopted for LibreSSL based on older code from relayd (by pyr@ and myself)
With feedback and OK bluhm@
deraadt