Mac OS/X has a type for %j that doesn't agree with how we define it,
which gives incorrect warnings.  The easiest way out of that situation
is simply to turn off that check on Mac OS/X.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5302)

As suggested in https://github.com/openssl/openssl/pull/5275Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5288)

Configurations/descrip.mms.tmpl didn't treat the includes config
attribute very well.  In fact, it didn't treat it at all!
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5295)

Simplify Posix timer detection.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5279)

The contents of that attribute is C file names, not object file names.
This went undetected because quite a lot of systems have assembler
implementations anyway, so setting OPENSSL_CPUID_OBJ was correct for
them.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5291)

Recent changes seem to have gotten OS X back on track, so we should be
able to run our tests there again.

This reverts commit e12e903e.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5292)

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

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

%disabled_algorithms isn't necessarily initialised with the "algos"
'DEPRECATEDIN_1_1_0' etc.  However, we know that @known_algorithms has
them all, so use that to find them instead.

Fixes #5157
(where this was reported)
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5282)

The slash should be there according to Microsoft documentation,
see https://msdn.microsoft.com/en-us/library/7cafx990.aspx

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

tls13encryptiontest is an "internal" test. As with all the other internal
tests it should not be run on a shared native Windows build.

[extended tests]
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5266)

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

If TLSv1.3 is enabled and combined with other options that extend the
size of the ClientHello, then the clienthello test can sometimes fail
because the ClientHello has grown too large. Part of the purpose of the
test is to check that the padding extension works properly. This requires
the ClientHello size to be kept within certain bounds.

By restricting the number of ciphersuites sent we can reduce the size of
the ClientHello.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5266)

[extended tests]
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5266)

It turns out that even if you successfully build the engine, it might
not load properly, so we cannot make the test program fail for it.

See the message in commit 25b9d11c

This reverts commit 227a1e3f.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5276)

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

If a module is disablable (i.e. can be configured with 'no-FOO'), the
resulting header file needs to be guarded with a check of the
corresponding OPENSSL_NO_FOO.  While this seem fairly innocuous, it
has an impact on the information in util/*.num, generated by mkdef.pl.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5275)

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

The afalg engine was moved down from engines/afalg/ to engines/, but
the test wasn't changed accordingly.  This was undetected because the
test program didn't fail when it couldn't load the engine.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5270)

If you know that there's no afalg engine, don't run this test.
test/recipes/30-test_afalg.t checks this correctly.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5270)

MacOS seems to define __GLIBC__ but not __GLIBC_PREREQ.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5269)

Remove the timer and TSC additional input code and instead provide a single
routine that attempts to use the "best" timer/counter available on the
system.  It attempts to use TSC, then various OS dependent resources and
finally several tries to obtain the date.  If any of these timer/counters
is successful, the rest are skipped.

No randomness is credited for this.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5231)

If such a timer/counter register is not available, the return value is always
zero.  This matches the assembly implementations' behaviour.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5231)

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

Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5268)

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

Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5230)

Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5230)

This script kept its own database of disablable algorithms, which is a
maintenance problem, as it's not always perfectly in sync with what
Configure does.  However, we do have all the data in configdata.pm,
produced by Configure, so let's use that instead.

Also, make sure to parse the *err.h header files, as they contain
function declarations that might not be present elsewhere.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5157)

The functions RAND_bytes() and RAND_priv_bytes() are now both based
on a common implementation using RAND_DRBG_bytes() (if the default
OpenSSL rand method is active). This not only simplifies the code
but also has the advantage that additional input from a high precision
timer is added on every generate call if the timer is available.
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5251)

When comparing the implementations of drbg_bytes() and RAND_DRBG_bytes(),
it was noticed that the former split the buffer into chunks when calling
RAND_DRBG_generate() to circumvent the size limitation of the buffer
to outlen <= drb->max_request. This loop was missing in RAND_DRBG_bytes(),
so it was adopted from drbg_bytes().
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5251)

This check not only prevented the automatic reinstantiation of the
DRBG, which is implemented in RAND_DRBG_generate(), but also prevented
an error message from being generated in the case of failure.
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5251)

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

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

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

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

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

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

The assumption that the received buffer has to be NUL-terminated was
faulty.

Fault found in #5224
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5239)

BN_from_montgomery_word doesn't have a constant memory access pattern.
Replace the pointer trick with a constant-time select. There is, of
course, still the bn_correct_top leak pervasive in BIGNUM itself.

See also https://boringssl-review.googlesource.com/22904 from BoringSSL.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5228)