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

This is needed for the upcoming "file" scheme STORE loader.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3542)

This is needed for the upcoming "file" scheme STORE loader.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3542)

This STORE module adds the following functionality:

- A function OSSL_STORE_open(), OSSL_STORE_load() and OSSL_STORE_close()
  that accesses a URI and helps loading the supported objects (PKEYs,
  CERTs and CRLs for the moment) from it.
- An opaque type OSSL_STORE_INFO that holds information on each loaded
  object.
- A few functions to retrieve desired data from a OSSL_STORE_INFO
  reference.
- Functions to register and unregister loaders for different URI
  schemes.  This enables dynamic addition of loaders from applications
  or from engines.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3542)

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

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

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

There aren't any test vectors for this, so all we do is test that both
sides of the communication create the same result for different protocol
versions.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3782)

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

Fix memory leak in sample encryption code and check return value of
fopen.

CLA: trivial
Signed-off-by: NGreg Zaverucha <gregz@microsoft.com>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3790)

Windows doesn't provide random().  In this particular case, our
requirements on the quality of randomness isn't high, so we don't
need to care how good randomness rand() does or doesn't provide.

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

Properly copy ext.alpn_session in ssl_session_dup()
Use OPENSSL_strndup() as that's used in ssl_asn1.c
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/3770)

uitest.o depends on apps.h which depends on progs.h, which is
dynamically generated, so we need to explicitely add a dependency
between uitest.o and progs.h for the latter to be generated in time.

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

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

The callback we're wrapping around may or may not return a
NUL-terminated string.  Let's ensure it is.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3791)

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

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

The BSD cryptodev.h doesn't have things like COP_FLAG_WRITE_IV and
COP_FLAG_UPDATE.  In that case, we need to implement that
functionality ourselves.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3744)

Based on cryptodev-linux
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3744)

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

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

Commit db17e43d added the function
but would improperly report success if the underlying dup operation
failed.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3775)

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

To make sure that our symbols don't clash with other libraries, we
claim the namespaces OSSL and OPENSSL.  Because C doesn't provide
namespaces, the only solution is to have them as prefixes on symbols,
thus we allow OSSL_ and OPENSSL_ as prefixes.

These namespace prefixes are optional for the foreseeable future, and
will only be used for new modules as needed on a case by case basis,
until further notice.

For extra safety, there's an added requirement that module names -
apart from the namespace prefix - be at least 2 characters long.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3781)

Breaks djgpp, masks a common kernel function name.
Thanks to Gisle Vanem for pointing this out.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3776)

To make it consistent in the code base
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/3749)

BIO_sock_init returns '-1' on error, not '0', so it's needed to check
explicitly istead of using '!'.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/3766)

As well as a coding style nit is fixed.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/3763)

This function is undocumented, but similarly named functions (such as
'curl_global_cleanup') are documented as internals that should not be
called by scripts.

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

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

Test for each of DSA, SHA1, and SHA224.

Use the symbolic names for SignatureScheme comparisons just added.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3326)

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

Put them into the TLSProxy::Message namespace along with the extension
type constants.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3326)

In draft-ietf-tls-tls13-20 Appendix B we find that:

   This section describes protocol types and constants.  Values listed
   as _RESERVED were used in previous versions of TLS and are listed
   here for completeness.  TLS 1.3 implementations MUST NOT send them
   but might receive them from older TLS implementations.

Similarly, in section 4.2.3 we see:

   Legacy algorithms  Indicates algorithms which are being deprecated
      because they use algorithms with known weaknesses, specifically
      SHA-1 which is used in this context with either with RSA using
      RSASSA-PKCS1-v1_5 or ECDSA.  These values refer solely to
      signatures which appear in certificates (see Section 4.4.2.2) and
      are not defined for use in signed TLS handshake messages.
      Endpoints SHOULD NOT negotiate these algorithms but are permitted
      to do so solely for backward compatibility.  Clients offering
      these values MUST list them as the lowest priority (listed after
      all other algorithms in SignatureSchemeList).  TLS 1.3 servers
      MUST NOT offer a SHA-1 signed certificate unless no valid
      certificate chain can be produced without it (see
      Section 4.4.2.2).

However, we are currently sending the SHA2-based DSA signature schemes
and many SHA1-based schemes, which is in contradiction with the specification.

Because TLS 1.3 support will appear in OpenSSL 1.1, we are bound by
stability requirements to continue to offer the DSA signature schemes
and the deprecated hash algorithms.  at least until OpenSSL 1.2.
However, for pure TLS 1.3 clients that do not offer lower TLS versions,
we can be compliant.  Do so, and leave a note to revisit the issue when
we are permitted to break with sacred historical tradition.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3326)

Curiously enough out-of-order Silvermont benefited most from
optimization, 33%. [Originally mentioned "anomaly" turned to be
misreported frequency scaling problem. Correct results were
collected under older kernel.]
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/3739)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/3739)

[extended tests]
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3760)

Something environmental changed in travis so that it started preferring
the ubuntu clang-3.9 version instead of the llvm.org one. This breaks the
sanitiser based builds. This change forces travis to de-prioritise the
ubuntu clang packages.

[extended tests]
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3759)

Following on from the previous commit this fixes another instance where
we need to treat a -ve return from EVP_DigestVerify() as a bad signature.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3756)

Prior to 72ceb6a6 we treated all failures from the call to
EVP_DigestVerifyFinal() as if it were a bad signature, and failures in
EVP_DigestUpdate() as an internal error. After that commit we replaced
this with the one-shot function EVP_DigestVerify() and treated a 0 return
as a bad signature and a negative return as an internal error. However,
some signature errors can be negative (e.g. according to the docs if the
form of the signature is wrong). Therefore we should treat all <=0
returns as a bad signature.

This fixes a boringssl test failure.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3756)