Previously, the API version limit was indicated with a numeric version
number. This was "natural" in the pre-3.0.0 because the version was
this simple number.
With 3.0.0, the version is divided into three separate numbers, and
it's only the major number that counts, but we still need to be able
to support pre-3.0.0 version limits.
Therefore, we allow OPENSSL_API_COMPAT to be defined with a pre-3.0.0
style numeric version number or with a simple major number, i.e. can
be defined like this for any application:
-D OPENSSL_API_COMPAT=0x10100000L
-D OPENSSL_API_COMPAT=3
Since the pre-3.0.0 numerical version numbers are high, it's easy to
distinguish between a simple major number and a pre-3.0.0 numerical
version number and to thereby support both forms at the same time.
Internally, we define the following macros depending on the value of
OPENSSL_API_COMPAT:
OPENSSL_API_0_9_8
OPENSSL_API_1_0_0
OPENSSL_API_1_1_0
OPENSSL_API_3
They indicate that functions marked for deprecation in the
corresponding major release shall not be built if defined.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7724)
Commit c7504aeb64 (pr #6432) fixed a regression for applications in
chroot environments, which compensated the fact that the new OpenSSL CSPRNG
(based on the NIST DRBG) now reseeds periodically, which the previous
one didn't. Now the reseeding could fail in the chroot environment if the
DEVRANDOM devices were not present anymore and no other entropy source
(e.g. getrandom()) was available.
The solution was to keep the file handles for the DEVRANDOM devices open
by default. In fact, the fix did more than this, it opened the DEVRANDOM
devices early and unconditionally in rand_pool_init(), which had the
unwanted side effect that the devices were opened (and kept open) even
in cases when they were not used at all, for example when the getrandom()
system call was available. Due to a bug (issue #7419) this even happened
when the feature was disabled by the application.
This commit removes the unconditional opening of all DEVRANDOM devices.
They will now only be opened (and kept open) on first use. In particular,
if getrandom() is available, the handles will not be opened unnecessarily.
This change does not introduce a regression for applications compiled for
libcrypto 1.1.0, because the SSLEAY RNG also seeds on first use. So in the
above constellation the CSPRNG will only be properly seeded if it is happens
before the forking and chrooting.
Fixes#7419
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7437)
... to make the intended use more clear and differentiate
it from the data member "adin_pool".
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7575)
Found by Coverity Scan
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7511)
Reviewed-by: Paul Yang <yang.yang@baishancloud.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7474)
Commit 5b4cb385c1 (#7382) introduced a bug which had the effect
that RAND_add()/RAND_seed() failed for buffer sizes less than
32 bytes. The reason was that now the added random data was used
exlusively as entropy source for reseeding. When the random input
was too short or contained not enough entropy, the DRBG failed
without querying the available entropy sources.
This commit makes drbg_add() act smarter: it checks the entropy
requirements explicitely. If the random input fails this check,
it won't be added as entropy input, but only as additional data.
More precisely, the behaviour depends on whether an os entropy
source was configured (which is the default on most os):
- If an os entropy source is avaible then we declare the buffer
content as additional data by setting randomness to zero and
trigger a regular reseeding.
- If no os entropy source is available, a reseeding will fail
inevitably. So drbg_add() uses a trick to mix the buffer contents
into the DRBG state without forcing a reseeding: it generates a
dummy random byte, using the buffer content as additional data.
Related-to: #7449
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7456)
Increase the load buffer size such that it exceeds the chunk
size by a comfortable amount. This is done to avoid calling
RAND_add() with a small final chunk. Instead, such a small
final chunk will be added together with the previous chunk
(unless it's the only one).
Related-to: #7449
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7456)
The failure of RAND_load_file was only noticed because of the
heap corruption which was reported in #7499 and fixed in commit
5b4cb385c1. To prevent this in the future, RAND_load_file()
now explicitly checks RAND_status() and reports an error if it
fails.
Related-to: #7449
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7456)
This bug was introduced by #7382 which enhanced RAND_add() to
accept large buffer sizes. As a consequence, RAND_add() now fails
for buffer sizes less than 32 bytes (i.e. less than 256 bits).
In addition, rand_drbg_get_entropy() forgets to reset the attached
drbg->pool in the case of an error, which leads to the heap corruption.
The problem occurred with RAND_load_file(), which reads the file in
chunks of 1024 bytes each. If the size of the final chunk is less than
32 bytes, then RAND_add() fails, whence RAND_load_file() fails
silently for buffer sizes n = k * 1024 + r with r = 1,...,31.
This commit fixes the heap corruption only. The other issues will
be addressed in a separate pull request.
Thanks to Gisle Vanem for reporting this issue.
Fixes#7449
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7455)
In pull request #4328 the seeding of the DRBG via RAND_add()/RAND_seed()
was implemented by buffering the data in a random pool where it is
picked up later by the rand_drbg_get_entropy() callback. This buffer
was limited to the size of 4096 bytes.
When a larger input was added via RAND_add() or RAND_seed() to the DRBG,
the reseeding failed, but the error returned by the DRBG was ignored
by the two calling functions, which both don't return an error code.
As a consequence, the data provided by the application was effectively
ignored.
This commit fixes the problem by a more efficient implementation which
does not copy the data in memory and by raising the buffer the size limit
to INT32_MAX (2 gigabytes). This is less than the NIST limit of 2^35 bits
but it was chosen intentionally to avoid platform dependent problems
like integer sizes and/or signed/unsigned conversion.
Additionally, the DRBG is now less permissive on errors: In addition to
pushing a message to the openssl error stack, it enters the error state,
which forces a reinstantiation on next call.
Thanks go to Dr. Falko Strenzke for reporting this issue to the
openssl-security mailing list. After internal discussion the issue
has been categorized as not being security relevant, because the DRBG
reseeds automatically and is fully functional even without additional
randomness provided by the application.
Fixes#7381
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7382)
Fixes a compiler warning about an unused syscall_random()
and cleans up the OPENSSL_RAND_SEED preprocessor logic.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/779)
Change all calls to getenv() inside libcrypto to use a new wrapper function
that use secure_getenv() if available and an issetugid then getenv if not.
CPU processor override flags are unchanged.
Extra checks for OPENSSL_issetugid() have been removed in favour of the
safe getenv.
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/7047)
It simply isn't available on older versions.
Issue submitted by Mark Daniels
Fixes#7229
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7230)
(cherry picked from commit d6d6aa3521)
The new DRBG API added the aforementioned #define. However, it is
used internally only and having it defined publicly does not serve
any purpose except causing potential version compatibility problems.
Fixes#7182
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7190)
Fixes#7022
In pull request #6432 a change was made to keep the handles to the
random devices opened in order to avoid reseeding problems for
applications in chroot environments.
As a consequence, the handles of the random devices were leaked at exit
if the random generator was not used by the application. This happened,
because the call to RAND_set_rand_method(NULL) in rand_cleanup_int()
triggered a call to the call_once function do_rand_init, which opened
the random devices via rand_pool_init().
Thanks to GitHub user @bwelling for reporting this issue.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7023)
Don't discard partial reads from /dev/*random and retry instead.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6990)
Fixes#6978
Don't discard partial reads from syscall_random() and retry instead.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6990)
Change return value type to ssize_t and ensure that a negative value
is returned only if a corresponding errno is set.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6990)
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/6778)
Occasionally, e.g. when compiling for elderly glibc, you end up passing
-D_GNU_SOURCE on command line, and doing so triggered warning...
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6616)
This allows operation inside a chroot environment without having the
random device present.
A new call, RAND_keep_random_devices_open(), has been introduced that can
be used to control file descriptor use by the random seed sources. Some
seed sources maintain open file descriptors by default, which allows
such sources to operate in a chroot(2) jail without the associated device
nodes being available.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/6432)
Unlike other ELF systems, HP-UX run-time linker fails to detect symbol
availability through weak declaration.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6583)
Calling the functions rand_pool_add_{additional,nonce}_data()
in crypto/rand/rand_lib.c with no implementation for djgpp/MSDOS
causees unresolved symbols when linking with djgpp.
Reported and fixed by Gisle Vanem
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6421)
If built with no-dso, syscall_random remains "blind" to getentropy.
Since it's possible to detect symbol availability on ELF-based systems
without involving DSO module, bypass it.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/6436)
If built with no-dso, DSO_global_lookup leaves "unsupported" message
in error queue. Since there is a fall-back code, it's unnecessary
distraction.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/6436)
Only Linux and FreeBSD provide getrandom(), but they both also provide
getentropy() since the same version and we already tried to call that.
Reviewed-by: Andy Polyakov <appro@openssl.org>
GH: #6405
This will actually support most OSs, and at least adds support for
Solaris and OSX
Fixes: #6403
Reviewed-by: Andy Polyakov <appro@openssl.org>
GH: #6405
Stop redefining structures that are already defined in system
headers. This also means we can stop setting the pointer size
globally, because the system structures will have the correct pointer
sizes either way. The only exception is passing the right pointer
size to a function.
Stop trying to twist things around with rand(), that's the job of the
DRBG that we feed.
Stop assuming the location of the JPI$_FINALEXC item, look it up
instead.
Signal an exception if the sys$getjpiw call fails (it means the item
list isn't set up right, so works as an assertion, but using VMS
methodology).
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6151)
No need to buildtest on opensslconf.h
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6149)
rand_pool_bytes_needed() was constructed in such a way that the
smallest acceptable entropy factor was 1 entropy bits per 8 bits of
data. At the same time, we have a DRBG_MINMAX_FACTOR that allows
weaker source, as small as 1 bit of entropy per 128 bits of data.
The conclusion is that rand_pool_bytes_needed() needs to change to
support weaker entropy sources. We therefore change the input of
entropy per byte to be an entropy factor instead. This entropy factor
expresses how many bits of data it takes (on average) to get 1 bit of
entropy.
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/6150)
