We copied $target{cflags}, $target{defines} and a few more to %config,
just to add to the entries.  Avoid doing so, and let the build templates
deal with combining the two.

There are a few cases where we still fiddle with %target, but that's
acceptable.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

The thread_cflag setting filled a double role, as kinda sorta an
indicator of thread scheme, and as cflags.  Some configs also added
lflags and ex_libs for multithreading regardless of if threading would
be enabled or not.

Instead of this, add threading cflags among in the cflag setting,
threading lflags in the lflag setting and so on if and only if threads
are enabled (which they are by default).

Also, for configs where there are no special cflags for threading (the
VMS configs are of that kind), this makes it possible to still clearly
mention what thread scheme is used.

The exact value of thread scheme is currently ignored except when it's
"(unknown)", and thereby only serves as a flag to tell if we know how
to build for multi-threading in a particular config.  Yet, the
currently used values are "(unknown)", "pthreads", "uithreads" (a.k.a
solaris threads) and "winthreads".
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Instead, make the build type ("debug" or "release") available through
$config{build_type} and let the configs themselves figure out what the
usual settings (such as "cflags", "lflags" and so on) should be
accordingly.

The benefit with this is that we can now have debug and release
variants of any setting, not just those Configure supports, and may
also involve other factors (the MSVC flags /MD[d] and /MT[d] involve
both build type and whether threading is enabled or not)
Reviewed-by: NAndy Polyakov <appro@openssl.org>

$target{lflags} and $target{plib_flag} were copied to %config for no
good reason.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Configure had the Unix centric addition of -lz when linking with zlib
is enabled, which doesn't work on other platforms.  Therefore, we move
it to the BASE_unix config template and add corresponding ones in the
other BASE_* config templates.  The Windows one is probably incomplete,
but that doesn't matter for the moment, as mk1mf does it's own thing
anyway.

This required making the %withargs table global, so perl snippets in
the configs can use it.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

These BASE templates are intended to hold values that are common for
all configuration variants for whole families of configurations.

So far, three "families" are identified: Unix, Windows and VMS, mostly
characterised by the build system they currently use.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

This provides for more powerful lazy evaluation and buildup of the
setting contents.  For example, something like this becomes possible:

    defines => [ sub { $config{thisorthat} ? "FOO" : () } ]

Any undefined result of such functions (such as 'undef' or the empty
list) will be ignored.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

The global thread local keys were not being deinited properly in async.
Reviewed-by: NRich Salz <rsalz@openssl.org>

The async code uses thread local variables. We should convert to using
the new Thread API for doing this.
Reviewed-by: NRich Salz <rsalz@openssl.org>

This patch provides getters for default_passwd_cb and userdata for SSL
and SSL_CTX. The getter functions are required to port Python's ssl module
to OpenSSL 1.1.0.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

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

This has no real meaning, except it gives Configure a hint that VC
targets are indeed capable of producing shared objects.
Reviewed-by: NMatt Caswell <matt@openssl.org>

We allow some commands to be overriden, but didn't handle that in a
consistent manner.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

There are cases, for example when configuring no-asm, that the added
uplink source files got in the way of the cpuid ones.  The best way to
solve this is to separate the two.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NDr. Stephen Henson <steve@openssl.org>

MR: #2184

Formally only 32-bit AVX2 code path needs this, but I choose to
harmonize all vector code paths.

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

Most of the assembly uses constants from arm_arch.h, but a few references to
ARMV7_NEON don't. Consistently use the macros everywhere.
Signed-off-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

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

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

Instead of overriding a default operation move default operation to a
separate function which is then explicitly included in any EC_METHOD
that uses it.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Specifies a callback that will, in the future, be used by the SSL code to
decide whether to abort a connection on Certificate Transparency grounds.
Reviewed-by: NBen Laurie <ben@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

The HOST_c2l() macro assigns the value to the specified variable, but also
evaluates to the same value. Which we ignore, triggering a warning.

To fix this, just cast it to void like we did in commit 08e55364
("Fix some clang warnings.") for a bunch of other instances.
Signed-off-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NBen Laurie <ben@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NBen Laurie <ben@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NBen Laurie <ben@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Tests included in future commit, which adds CT policy validation.
Reviewed-by: NBen Laurie <ben@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

and reorganize/harmonize post-conditions.

Additional hardening following on from CVE-2016-0702
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

At the same time remove miniscule bias in final subtraction.
Performance penalty varies from platform to platform, and even with
key length. For rsa2048 sign it was observed to be 4% for Sandy
Bridge and 7% on Broadwell.

CVE-2016-0702
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Performance penalty is 2%.

CVE-2016-0702
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Performance penalty is 2% on Linux and 5% on Windows.

CVE-2016-0702
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Performance penalty varies from platform to platform, and even
key length. For rsa2048 sign it was observed to reach almost 10%.

CVE-2016-0702
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NAndy Polyakov <appro@openssl.org>

Signed-off-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

in s_server cmd:
specifying -trace option, falls through and turn-on security_debug
Signed-off-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Signed-off-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

In the BN_hex2bn function the number of hex digits is calculated using
an int value |i|. Later |bn_expand| is called with a value of |i * 4|.
For large values of |i| this can result in |bn_expand| not allocating any
memory because |i * 4| is negative. This leaves ret->d as NULL leading
to a subsequent NULL ptr deref. For very large values of |i|, the
calculation |i * 4| could be a positive value smaller than |i|. In this
case memory is allocated to ret->d, but it is insufficiently sized
leading to heap corruption. A similar issue exists in BN_dec2bn.

This could have security consequences if BN_hex2bn/BN_dec2bn is ever
called by user applications with very large untrusted hex/dec data. This is
anticipated to be a rare occurrence.

All OpenSSL internal usage of this function uses data that is not expected
to be untrusted, e.g. config file data or application command line
arguments. If user developed applications generate config file data based
on untrusted data then it is possible that this could also lead to security
consequences. This is also anticipated to be a rare.

Issue reported by Guido Vranken.

CVE-2016-0797
Reviewed-by: NAndy Polyakov <appro@openssl.org>

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