It was calling the BN_rand() when it should have call BN_priv_rand()
Reviewed-by: NTim Hudson <tjh@openssl.org>
GH: #5514

Either files or directories of *.cnf or *.conf files
can be included.
Recursive inclusion of directories is not supported.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5351)

This fixes an issue raised in PR #4964 by kaduk.
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5491)

They are valid for use in a CertificateRequest message, but we did not
allow it. If a server sent such a message using either of those two
extensions then the handshake would abort.

This corrects that error, but does not add support for actually processing
the extensions. They are simply ignored, and a TODO is inserted to add
support at a later time.

This was found during interoperability testing with btls:
https://gitlab.com/ilari_l/btls

Prompted by these errors I reviewed the complete list of extensions and
compared them with the latest table in draft-24 to confirm there were no
other errors of a similar type. I did not find any.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5490)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5470)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5470)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5470)

Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5508)

Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5504)

Rely on the build.info constructor to do the right thing.

Fixes #5500
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5501)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5493)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5493)

Debugging asserts had implicit casts that triggered the warnings.
However, instead of making the casts explicit it's more appropriate
to perform checks that ensure that implicit casts were safe.

ec/curve448/scalar.c: size_t-fy scalar_decode_short.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5494)

Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5494)

Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5489)

Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5498)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5481)

This adds the Ed448 test vectors from RFC8032 and the X448 test vectors
from RFC7748.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5481)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5481)

This adds all of the relevant EVP plumbing required to make
X448 and Ed448 work.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5481)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5481)

CLA: trivial
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5458)

CLA: trivial
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4966)

Why is it redundant? We're looking at carry from addition of small,
11-bit number to 256-bit one. And carry would mean only one thing,
resulting first limb being small number and remaing ones - zeros.
Hence adding 38 to first limb can't carry.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5476)

When early data support was first added, this seemed like a good
idea, as it would allow applications to just add SSL_read_early_data()
calls as needed and have things "Just Work".  However, for applications
that do not use TLS 1.3 early data, there is a negative side effect.
Having a nonzero max_early_data in a SSL_CTX (and thus, SSL objects
derived from it) means that when generating a session ticket,
tls_construct_stoc_early_data() will indicate to the client that
the server supports early data.  This is true, in that the implementation
of TLS 1.3 (i.e., OpenSSL) does support early data, but does not
necessarily indicate that the server application supports early data,
when the default value is nonzero.  In this case a well-intentioned
client would send early data along with its resumption attempt, which
would then be ignored by the server application, a waste of network
bandwidth.

Since, in order to successfully use TLS 1.3 early data, the application
must introduce calls to SSL_read_early_data(), it is not much additional
burden to require that the application also calls
SSL_{CTX_,}set_max_early_data() in order to enable the feature; doing
so closes this scenario where early data packets would be sent on
the wire but ignored.

Update SSL_read_early_data.pod accordingly, and make s_server and
our test programs into applications that are compliant with the new
requirements on applications that use early data.

Fixes #4725
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5483)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
GH: #4672

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5477)

Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4008)

Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4008)

Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4008)

Related to #3709
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4008)

Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3709)

Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3709)

This is to address issue #3404, only works in Unix-like platforms
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3709)

Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5482)

Thumb2 addresses are a bit a mess, depending on whether a label is
interpreted as a function pointer value (for use with BX and BLX) or as
a program counter value (for use with PC-relative addressing). Clang's
integrated assembler mis-assembles this code. See
https://crbug.com/124610#c54 for details.

Instead, use the ADR pseudo-instruction which has clear semantics and
should be supported by every assembler that handles the OpenSSL Thumb2
code. (In other files, the ADR vs SUB conditionals are based on
__thumb2__ already. For some reason, this one is based on __APPLE__, I'm
guessing to deal with an older version of clang assembler.)

It's unclear to me which of clang or binutils is "correct" or if this is
even a well-defined notion beyond "whatever binutils does". But I will
note that https://github.com/openssl/openssl/pull/4669 suggests binutils
has also changed behavior around this before.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5431)

CLA: trivial
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5473)

And only generate one output "file" at a time for objects.pl
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5432)

Fixes #5471
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5472)

Fixes #5471
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5472)