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

This commit adds a new api RAND_DRBG_set_defaults() which sets the
default type and flags for new DRBG instances. See also #5576.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5632)

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

There were a few environment variables that we supported in earlier
Configure versions which got transfered to the %user table.  This
change makes sure that we still support them, by simply pre-populating
the corresponding %user entries with those environment values.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5641)

The original intent was that if someone had a "make variable" set in
any kind of way, be it as an environment variable or as an argument to
Configure, we wouldn't allow compiler or linker flags as arguments as
well.  That made both of these configurations equivalently impossible:

    ./Configure target CFLAGS=-foo -lextra

     CFLAGS=-foo ./Configure target -lextra

While this makes things look nice and consistent, real world use makes
this hard, as many projects where OpenSSL is a component also set
these variables for other components that use GNU autotools.

Therefore, we need to adapt our Configure accordingly.  By
consequence, the two Configure lines above will not be equivalent any
more:

    ./Configure target CFLAGS=-foo -lextra

This command line will still fail, because the "make variable" was
given as a command line argument.  This cannot be a mistake and is
therefore not allowed.

     CFLAGS=-foo ./Configure target -lextra

This command line will work, but because there is a linker flag as
a command line argument, the environment (i.e. CFLAGS) is ignored.
That isn't quite consistent with the previous command, but is the old
Configure behavior, before the support for "make variables" was added,
and is therefore the backward compatible behavior.

Fixes google/oss-fuzz#1244
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5641)

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

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

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

In the end, it's more efficient to only have one perl instance (that
loads configdata.pm) dealing with dependency files than running one
(that still loads configdata.pm) for each such file.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5631)

Affected symbol names:

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

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

Fixes #4403

This commit moves the internal header file "internal/rand.h" to
<openssl/rand_drbg.h>, making the RAND_DRBG API public.
The RAND_POOL API remains private, its function prototypes were
moved to "internal/rand_int.h" and converted to lowercase.

Documentation for the new API is work in progress on GitHub #5461.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5462)

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

Instead of just working line by line, we collect all dependencies for
every target and print everything out at the end, with each target
getting a potentially long list of dependencies.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5591)

All dependencies that VC gives us are absolute paths, so we need to
check if some of them are within our source or build tree.  We do that
by comparing the start of each dependency with the absolute versions
of our source and build directories.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5591)

It seems that only gcc -MMD produces dependency files that are "sane"
for our needs.  For all other methods, some post processing is needed:

- 'makedepend' (Unix) insists that object files are located in the
  same spot as the source file.
- 'cl /Zs /showIncludes' (Visual C) has "Note: including file: " where
  we'd like to see the object.
- 'CC/DECC' (VMS) insists that the object file is located in the
  current directory, i.e. it strips away all directory information.

So far, we've managed this (except for the VMS case) with individual
uncommented perl command lines directly in the build file template.
We're now collecting these diverse hacks into one perl script that
takes an argument to tell what kind of input to expect and that
massages whatever it gets on STDIN and outputs the result on STDOUT.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5591)

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

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

It is quite likely for there to be multiple certificates with empty
subjects, which are still distinct because of subjectAltName. Therefore
we allow multiple certificates with an empty Subject even if
unique_subject is set to yes.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5444)

Commit 87e8feca (16 years ago!) introduced a bug where if we are
attempting to insert a cert with a duplicate subject name, and
duplicate subject names are not allowed (which is the default),
then we get an unhelpful error message back (error number 2). Prior
to that commit we got a helpful error message which displayed details
of the conflicting entry in the database.

That commit was itself attempting to fix a bug with the noemailDN option
where we were setting the subject field in the database too early
(before extensions had made any amendments to it).

This PR moves the check for a conflicting Subject name until after all
changes to the Subject have been made by extensions etc.

This also, co-incidentally fixes the ca crashing bug described in issue
5109.

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

This reverts commit e505f1e8.

Empty Subjects should be permissible.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5444)

This reverts commit 1e05c6d0.

Empty subjects should be permissible.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5444)

Renamed to EVP_PKEY_new_raw_private_key()/EVP_new_raw_public_key() as per
feedback.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5520)

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

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

Include more information about how to create keys for these algorithms.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5520)

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

Previously private and public keys had to be pem encoded to be read by
evp_test. This enables us to embed the raw private/public key values
in the test file. The algorithm has to support EVP_PKEY_new_private_key()
and EVP_PKEY_new_public_key() for this to work.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5520)

Also adds some documentation for related existing functions/macros
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5520)

Also to use the new EVP_PKEY_new_CMAC_key()
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5520)

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

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

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

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

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

Not all algorithms will support this, since their keys are not a simple
block of data. But many can.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5520)

The Debian build system uses a `debian' target which sets CFLAGS and
then we have for instance debian-amd64 which inherits from
linux-x86_64 and debian [0]. So far so good.

Unless there are different suggestions how to do this, I would keep it.
However since the target name does not start with `linux', the build
system does not enable the afalg engine. So in order to get enabled, I
added a
	`enable           => [ "afalgeng" ],'
to the generic linux config which sets it explicit (as suggested by
Richard Levitte). Having this set, we can check for it instead matching
the target name.

[0] https://sources.debian.org/src/openssl/1.1.0g-2/Configurations/20-debian.conf/Signed-off-by: NSebastian Andrzej Siewior <sebastian@breakpoint.cc>
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5169)

In TLSv1.3 the session is not ready until after the end of the handshake
when we are constructing the NewSessionTicket.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5621)

Added two missing OIDs for AES-{128,256}-XTS.
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5622)

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