The af_alg engine and associated test were creating warnings when compiled
with clang. This fixes it.

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

The new afalg test should have a copyright date of 2016. Also an
incorrect buffer was being sent to EVP_CipherFinal_ex when
decrypting.

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

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>

The 0x00010000L OPENSSL_INIT flag appeared twice.

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

Misc afalg build fixes as suggested by Richard Levitte for the latest
Configure changes.

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

1. Cleaned up eventfd handling
2. Reworked socket setup code to allow other algorithms to be added in
   future
3. Fixed compile errors for static build
4. Added error to error stack in all cases of ALG_PERR/ALG_ERR
5. Called afalg_aes_128_cbc() from bind() to avoid race conditions
6. Used MAX_INFLIGHT define in io_getevents system call
7. Coding style fixes

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>

- Remove Win builds (temporarily). They're slow, allowed to fail,
  and therefore not useful as they are.
- Make the --unified part of the matrix build-only. (This can be
  swapped if --unified becomes the default)
- Only build 'no-engine' once, don't run any tests, but don't allow it
  to fail.

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

- Remove no-asm. We've got to cut something, and this is at least
  partially covered by the sanitizer builds.
- Remove enable-crypto-mdebug from sanitizer
  builds. enable-crypto-mdebug has been shown to catch some static
  initialization bugs that the standard leak sanitizer can't so
  perhaps it has _some_ value; but we shouldn't let the two compete.

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

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>

When object files with common block symbols are added to static
libraries on Darwin, those symbols are invisible to the linker that
tries to use them.  Our solution was to use -fno-common when compiling
C source.

Unfortunately, there is assembler code that defines OPENSSL_ia32cap_P
as a common block symbol, unconditionally, and in some cases, there is
no other definition.  -fno-common doesn't help in this case.

However, 'ranlib -c' adds common block symbols to the index of the
static library, which makes them visible to the linker using it, and
that solves the problem we've seen.

The common conclusion is, either use -fno-common or ranlib -c on
Darwin.  Since we have common block symbols unconditionally, choosing
the method for our source is easy.

Reviewed-by: Kurt Roeckx <kurt@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Thanks to Colin Percival for reporting this issue.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Emilia Kasper <emilia@openssl.org>

MR: #2203

They're not part of ALL, so they're not part of COMPLEMENTOFDEFAULT

Reviewed-by: Rich Salz <rsalz@openssl.org>

MR: #2202

Clang is permissive of this, but gcc fails.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Add support for application supplied any defined by callback. An
application can change the selector value if it wishes. This is
mainly intended for values which are only known at runtime, for
example dynamically created OIDs.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>

Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

e.g. "enabled_logs = foo,,bar"

Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Previously, the remaining CT log entries would not be loaded.
Also, CTLOG_STORE_load_file would return 1 even if a log entry was
invalid, resulting in no errors being shown.

Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Disabled by default, but can be enabled by setting the
ct_validation_callback on a SSL or SSL_CTX.

Reviewed-by: Ben Laurie <ben@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Change the ECC default curve list to be this, in order: x25519, secp256r1,
secp521r1, secp384r1, brainpoolP256r1, brainpoolP384r1, and brainpool512r1.

Reviewed-by: Emilia Käsper <emilia@openssl.org>

Appease the sanitizer: avoid left shifts of negative values.

This could've been done entirely with casts to uint and back,
but using masks seemed slightly more readable.

There are also implementation-defined signed right shifts in this
code. Those remain.

Reviewed-by: Rich Salz <rsalz@openssl.org>

RT#4365

Reviewed-by: Rich Salz <rsalz@openssl.org>

RC4 based ciphersuites in libssl have been disabled by default. They can
be added back by building OpenSSL with the "enable-weak-ssl-ciphers"
Configure option at compile time.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>

The proper logic is that both zlib and zlib-dynamic are disabled by
default and that enabling zlib-dynamic would enable zlib.  Somewhere
along the way, the logic got changed, zlib-dynamic was enabled by
default and zlib didn't get automatically enabled.

This change restores the original logic.

Reviewed-by: Rich Salz <rsalz@openssl.org>

PVK files with abnormally large length or salt fields can cause an
integer overflow which can result in an OOB read and heap corruption.
However this is an rarely used format and private key files do not
normally come from untrusted sources the security implications not
significant.

Fix by limiting PVK length field to 100K and salt to 10K: these should be
more than enough to cover any files encountered in practice.

Issue reported by Guido Vranken.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Signed-off-by: Rich Salz <rsalz@akamai.com>
Reviewed-by: Matt Caswell <matt@openssl.org>

Signed-off-by: Rich Salz <rsalz@akamai.com>
Reviewed-by: Matt Caswell <matt@openssl.org>