It's actually not a real issue but caused by the absence of the default case
which does not occur in reality but which makes coverity see a code path where
pkey remains unassigned.

Reported by Coverity Scan (CID 1423323)
[extended tests]
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7158)

Reported by Coverity Scan (CID 1439138)
[extended tests]
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7156)

Reported by Coverity Scan (CID 1439136)
[extended tests]
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7155)

The deprecated ASN.1 type LONG / ZLONG (incorrectly) produced zero
length INTEGER encoding for zeroes.  For the sake of backward
compatibility, we allow those to be read without fault when using the
replacement types INT32 / UINT32 / INT64 / UINT64.

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

Confirms #7134
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7153)

This was originally part of SipHash_Init.  However, there are cases
where there isn't any key material to initialize from when setting the
hash size, and we do allow doing so with a EVP_PKEY control.  The
solution is to provide a separate hash_size setter and to use it in
the corresponding EVP_PKEY_METHOD.

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

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

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

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

PR #3783 introduce coded to reset the server side SNI state in
SSL_do_handshake() to ensure any erroneous config time SNI changes are
cleared. Unfortunately SSL_do_handshake() can be called mid-handshake
multiple times so this is the wrong place to do this and can mean that
any SNI data is cleared later on in the handshake too.

Therefore move the code to a more appropriate place.

Fixes #7014
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/7149)

Ideally, SSL_get_servername() would do exactly as it is documented
and return exactly what the client sent (i.e., what we currently
are stashing in the SSL's ext.hostname), without needing to refer
to an SSL_SESSION object.  For historical reasons, including the
parsed SNI value from the ClientHello originally being stored in the
SSL_SESSION's ext.hostname field, we have had references to the
SSL_SESSION in this function.  We cannot fully excise them due to
the interaction between user-supplied callbacks and TLS 1.2 resumption
flows, where we call all callbacks but the client did not supply an
SNI value.  Existing callbacks expect to receive a valid SNI value
in this case, so we must fake one up from the resumed session in
order to avoid breakage.

Otherwise, greatly simplify the implementation and just return the
value in the SSL, as sent by the client.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7115)

Commit 1c4aa31d modified the state machine
to clean up stale ext.hostname values from SSL objects in the case when
SNI was not negotiated for the current handshake.  This is natural from
the TLS perspective, since this information is an extension that the client
offered but we ignored, and since we ignored it we do not need to keep it
around for anything else.

However, as documented in https://github.com/openssl/openssl/issues/7014 ,
there appear to be some deployed code that relies on retrieving such an
ignored SNI value from the client, after the handshake has completed.
Because the 1.1.1 release is on a stable branch and should preserve the
published ABI, restore the historical behavior by retaining the ext.hostname
value sent by the client, in the SSL structure, for subsequent retrieval.

[extended tests]
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7115)

The is_tls13_capable() function should not return 0 if no certificates
are configured directly because a certificate callback is present.

Fixes #7140
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7141)

That function was removed in favour of SSL_set_post_handshake_auth().
Update the docs accordingly.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7139)

Even though we already sent close_notify the server may not have recieved
it yet and could issue a CertificateRequest to us. Since we've already
sent close_notify we can't send any reasonable response so we just ignore
it.
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7114)

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

If we've sent a close_notify then we are restricted about what we can do
in response to handshake messages that we receive. However we can sensibly
process NewSessionTicket messages. We can also process a KeyUpdate message
as long as we also ignore any request for us to update our sending keys.
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7114)

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

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

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

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

This test case is originally submitted in #6757, by Jack Lloyd. The test
case has been modified to use the a different method to set the ID when
computing the Z hash of SM2 signature.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NPaul Yang <yang.yang@baishancloud.com>
(Merged from https://github.com/openssl/openssl/pull/7113)

zero-length ID is allowed, but it's not allowed to skip the ID.

Fixes: #6534
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7113)

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

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

Thus users can use this function to set customized EVP_PKEY_CTX to
EVP_MD_CTX structure.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7113)

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

Signed-off-by: NPatrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/7138)

This addresses issue #6922.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7073)

Put a NULL check back in to avoid dereferencing the NULL pointer.
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7146)

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

Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7105)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7121)

`RSA_free()` and friends are called in case of error from
`RSA_new_method(ENGINE *e)` (or the respective equivalent functions).

For the rest of the description I'll talk about `RSA_*`, but the same
applies for the equivalent `DSA_free()`, `DH_free()`, `EC_KEY_free()`.

If `RSA_new_method()` fails because the engine does not implement the
required method, when `RSA_free(RSA *r)` is called,
`r->meth == NULL` and a segfault happens while checking if
`r->meth->finish` is defined.

This commit fixes this issue by ensuring that `r->meth` is not NULL
before dereferencing it to check for `r->meth->finish`.

Fixes #7102 .
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7121)

-subj 'subject=C = US, ST = A, L = root, O = Hewlett Packard Enterprise Company, OU = Remote Device Access, CN = Hewlett Packard Enterprise Remote Device Access Test Local CA, emailAddress = rda@hpe.com'
was a valid subject in openssl 1.0. Error received in 1.1 is:

problems making Certificate Request

Not very informative, I only figured this out because I compiled the
code and added logging.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7098)

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

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

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

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

With the introduction of -pkeyopt, the number of bits may change
without |newkey| being updated.  Unfortunately, there is no API to
retrieve the information from a EVP_PKEY_CTX either, so chances are
that we report incorrect information.  For the moment, it's better not
to try to report the number of bits at all.

Fixes #7086
Reviewed-by: NPaul Yang <yang.yang@baishancloud.com>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7096)