This function makes it easier to retrieve a reference to the
  authority key identifier (akid->keyid) inside a certificate.
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5271)

According to TLSv1.3 draft-24 the record version for ClientHello2 should
be TLS1.2, and not TLS1.0 as it is now.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5377)

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

Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5396)

Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5396)

All contexts must be initialised because they can only be created using the _new() calls.
Remove the outdated mentions of uninitialised and initialised contexts.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5388)

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

The description was probably copy&pasted from pkey.pod and forgotten.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5390)

Most of all, this is so it doesn't output mysterious text when we're
treating the phony config targets LISH, HASH and TABLE
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5383)

In previous OpenSSL versions, this letter was part of the make
variable AR.  However, following the usual convention (read: GNU),
this letter is supposed to be part of ARFLAGS.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5386)

The function can fail so we should check the return code.

Found by Coverity
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/5339)

Check for a failure and free a_tm as appropriate.

Found by Coverity
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/5339)

Coverity was complaining because we checked if s->ctx is NULL and then
later on in the function deref s->ctx anyway. In reality if s->ctx is
NULL then this is an internal error.
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5334)

In PR #5295 it was decided that the locking api should remain private
and used only inside libcrypto. However, the locking functions were added
back to `libcrypto.num` by `mkdef.pl`, because the function prototypes
were still listed in `internal/rand.h`. (This header contains functions
which are internal, but shared between libcrypto and libssl.)

This commit moves the prototypes to `rand_lcl.h` and changes the names
to lowercase, following the convention therein. It also corrects an
outdated documenting comment.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5375)

Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5373)

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

configdata.pm -d prints out a lot of information, including a table
of what features are disabled, why, and the effect of that disablement
(in terms of preprocessor symbols defined and directories skipped).
The first column is already auto-sized, to easily accomodate future
disableable features with long names.  Also auto-size the second column,
to accomodate future reasons for disablement with long names as well.

Failing to take such precautions results in stderr spew from
configdata.pm -d when such long reasons are in use:

   Negative repeat count does nothing at ./configdata.pm line 14504.

Such output is pretty distracting from the actual desired output,
so try to avoid it if possible.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5371)

It's a convenient complement to OSSL_STORE_ctrl()

Suggested by Norm Green
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5363)

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

Avoid using crypto/modes/ghash-ia64.s, as it uses features that are
explicitely prohibited on VMS.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5357)

On VMS, 'abort' is really 'decc$abort'
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5357)

This does require the use of a port of 'ias' for VMS.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5357)

The make variables LIB_CFLAGS, DSO_CFLAGS and so on were used in
addition to CFLAGS and so on.  This works without problem on Unix and
Windows, where options with different purposes (such as -D and -I) can
appear anywhere on the command line and get accumulated as they come.
This is not necessarely so on VMS.  For example, macros must all be
collected and given through one /DEFINE, and the same goes for
inclusion directories (/INCLUDE).

So, to harmonize all platforms, we repurpose make variables starting
with LIB_, DSO_ and BIN_ to be all encompassing variables that
collects the corresponding values from CFLAGS, CPPFLAGS, DEFINES,
INCLUDES and so on together with possible config target values
specific for libraries DSOs and programs, and use them instead of the
general ones everywhere.

This will, for example, allow VMS to use the exact same generators for
generated files that go through cpp as all other platforms, something
that has been impossible to do safely before now.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5357)

The 'pp' function parameters of d2i_TYPE() and i2d_TYPE() are referenced
in the DESCRIPTION section as 'in' resp. 'out'. This commit renames the
references to 'ppin' resp. 'ppout' and adds an explaining sentence.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5365)

The s_client psk_use_session_cb callback has a comment stating that we
should ignore a key that isn't suitable for TLSv1.3. However we were
actually causing the connection to fail. Changing the return value fixes
the issue.

Also related to this is that the early_data extension was not marked as
TLSv1.3 only which it should be.

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

Commit 42d7d7dd turned this function from returning void to
returning an int error code. This instance of calling it was
missed.

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

Found by Coverity.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5336)

Instead of having the knowledge of the exact flags to run the C
preprocessor only and have it output on standard output in the deeper
recesses of the build file template, make it a config parameter, or
rely on build CPP in value ('$(CC) -E' on Unix).
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5356)

All VMS config targets were literally copies of each other, only
differing in what argument the parameter seeking function vms_info()
received (the pointer size).

This could be hugely simplified by letting vms_info() detect what
pointer size was desired from the desired config target name instead.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5364)

This is purported to save a few cycles, but makes the code less
obvious and more brittle, and in fact breaks on platforms where for
ABI continuity reasons there is a SHA2 implementation in libc, and
so EVP needs to call those to avoid conflicts.

A sufficiently good optimizer could simply generate the same entry
points for:

        foo(...) { ... }
    and
        bar(...) { return foo(...); }

but, even without that, the different is negligible, with the
"winner" varying from run to run (openssl speed -evp sha384):

    Old:
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
    sha384           28864.28k   117362.62k   266469.21k   483258.03k   635144.87k 649123.16k

    New:
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
    sha384           30055.18k   120725.98k   272057.26k   482847.40k   634585.09k 650308.27k
Reviewed-by: NRich Salz <rsalz@openssl.org>

getrandom() is now used on Linux by default when using Linux >= 3.17
and glibc >= 2.25
Reviewed-by: NRich Salz <rsalz@openssl.org>
GH: #5314

Without that, output comes one character per line.  It's the same
issue as has been observed before, this happens when using write()
on a record oriented stream (possibly unbuffered too).

This also uncovered a bug in BIO_f_linebuffer, where this would cause
an error:

    BIO_write(bio, "1\n", 1);

I.e. there's a \n just after the part of the string that we currently
ask to get written.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5352)

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

.. if avalable. STCK has an artificial delay to ensure uniqueness
which can result in a performance penalty if used heavily
concurrently.
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/5284)

Output copyright year depends on any input file(s) and the script.
This is not perfect, but better than what we had.
Also run 'make update'
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5350)

If the global DRBGs are allocated on the secure heap, then calling
CRYPTO_secure_malloc_done() inside main() will have no effect, unless
OPENSSL_cleanup() has been called explicitely before that, because
otherwise the DRBGs will still be allocated. So it is better to cleanup
the secure heap automatically at the end of OPENSSL_cleanup().
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5294)

The NIST standard presents two alternative ways for seeding the
CTR DRBG, depending on whether a derivation function is used or not.
In Section 10.2.1 of NIST SP800-90Ar1 the following is assessed:

  The use of the derivation function is optional if either an
  approved RBG or an entropy source provides full entropy output
  when entropy input is requested by the DRBG mechanism.
  Otherwise, the derivation function shall be used.

Since the OpenSSL DRBG supports being reseeded from low entropy random
sources (using RAND_POOL), the use of a derivation function is mandatory.
For that reason we change the default and replace the opt-in flag
RAND_DRBG_FLAG_CTR_USE_DF with an opt-out flag RAND_DRBG_FLAG_CTR_NO_DF.
This change simplifies the RAND_DRBG_new() calls.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5294)

The functions drbg_setup() and drbg_cleanup() used to duplicate a lot of
code from RAND_DRBG_new() and RAND_DRBG_free(). This duplication has been
removed, which simplifies drbg_setup() and makes drbg_cleanup() obsolete.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5294)

This commit adds three new accessors to the internal DRBG lock

   int RAND_DRBG_lock(RAND_DRBG *drbg)
   int RAND_DRBG_unlock(RAND_DRBG *drbg)
   int RAND_DRBG_enable_locking(RAND_DRBG *drbg)

The three shared DRBGs are intended to be used concurrently, so they
have locking enabled by default. It is the callers responsibility to
guard access to the shared DRBGs by calls to RAND_DRBG_lock() and
RAND_DRBG_unlock().

All other DRBG instances don't have locking enabled by default, because
they are intendended to be used by a single thread. If it is desired,
locking can be enabled by using RAND_DRBG_enable_locking().
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5294)

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