It was added as part of 2df84dd3
but has never actually been used for anything; presumably it was
a typo for one of SCTP or CT.

This removes the last '??' entry from INSTALL.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Commit d064e6ab removed all the
OPENSSL_NO_SHA guards, but commit
a50ad1da regenerated some due to the
sha entries in the %md_disabler table in apps/progs.pl.

Update %md_disabler to reflect that sha is not disableable, and
remove OPENSSL_NO_SHA for good.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

Even though no test could be found to trigger this, paper-n-pencil
estimate suggests that x86 and ARM inner loop lazy reductions can
loose a bit in H4>>*5+H0 step.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

And recycle some disused slots.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

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

In the case of generating a file like this:

    GENERATE[foo.S]=mkfoo.pl arg1 arg2

the 'mkfoo.pl' generator itself might need to include other files,
such as perl modules within our source tree.  We can reuse already
existing syntax for it, like this:

    INCLUDE[mkfoo.pl]=module/path

or:

    DEPEND[mkfoo.pl]=modules/mymodule.pm

This change implements the support for such constructs, and for the
DEPEND statement, for any value that indicates a perl module (.pm
file), it will automatically infer an INCLUDE statement for its
directory, just like it does for C header files, so you won't have do
write this:

    DEPEND[mkfoo.pl]=modules/mymodule.pm
    INCLUDE[mkfoo.pl]=modules
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Thanks to Brian Carpenter for finding and reporting this.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

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

IBM argues that in certain scenarios capability query is really
expensive. At the same time it's asserted that query results can
be safely cached, because disabling CPACF is incompatible with
reboot-free operation.
Reviewed-by: NTim Hudson <tjh@openssl.org>

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

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

Fix a bug introduced by 6903e2e7 (Extended EC_METHOD customisation
support., 2016-02-01). key->meth->set_private() is wrongly called where
it should call key->group->meth->set_private().

PR#4517
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NStephen Henson <steve@openssl.org>

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

Bad ASN.1 data should never be able to trigger a malloc failure so return
an error in d2i_test if a malloc failure occurs.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

If the ASN.1 BIO is presented with a large length field read it in
chunks of increasing size checking for EOF on each read. This prevents
small files allocating excessive amounts of data.

CVE-2016-2109

Thanks to Brian Carpenter for reporting this issue.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

The reason to warn is that configuration *may* pick up on
configuration header files that are in the source tree, that might be
for a wildly different configuration than what is expected in the
current out-of-source configuration.
Reviewed-by: NMatt Caswell <matt@openssl.org>

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

It is up to the caller of SSL_dane_tlsa_add() to take appropriate
action when no records are added successfully or adding some records
triggers an internal error (negative return value).

With this change the caller can continue with PKIX if desired when
none of the TLSA records are usable, or take some appropriate action
if DANE is required.

Also fixed the internal ssl_dane_dup() function to properly initialize
the TLSA RR stack in the target SSL handle.  Errors in ssl_dane_dup()
are no longer ignored.
Reviewed-by: NRich Salz <rsalz@openssl.org>

If we fail halfway through constructing the peer_tmp EVP_PKEY but we have
already stored it in s->s3->peer_tmp then if anything tries to use it then
it will likely fail. This was causing s_client to core dump in the
sslskewith0p test. s_client was trying to print out the connection
parameters that it had negotiated so far. Arguably s_client should not do
that if the connection has failed...but given it is existing functionality
it's easier to fix libssl.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

Using ASN1_ITEM tables in d2i_test: this then uses consistent names and
makes it easier to extend.

Add bio, reencode and compare tests.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

The capi engine was failing to compile on Windows if the no-dsa option
was selected.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

The no-dsa option was failing on Windows because some symbols were not
correctly flagged in libcrypto.num. Problem found due to the new symbol
consistency test.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Some pre-processor macros were incorrectly indented
Reviewed-by: NRichard Levitte <levitte@openssl.org>

no-cmac was failing on Windows/VMS due to libcrypto.num not marking the
CMAC functions properly. Found due to the new symbol consistency test.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

Our main development platforms are of the Unix family, which doesn't
have the same strictness regarding a shared library being consistent
with the contents of the ld script (.map file, on Linux and Solaris)
as Windows is with the contents of the .def file or VMS is with the
linker symb_vector option.

To eliminate surprises, we therefore need to make sure to check that
the contents of the .map file is matched with the shared library, at
least to check that the shared library isn't missing any symbols that
should be present.

This test isn't absolutely perfect, as it will only check the symbols
that would be present on Linux / Solaris and will therefore miss those
that would only appear on Windows or VMS.  On the other hand, those
platform specific are few and far apart in time, so it's not likely
they will pose a problem.
Reviewed-by: NMatt Caswell <matt@openssl.org>

If allocation in CRYPTO_clear_realloc() fails don't free up the original
buffer: this is consistent with the behaviour of realloc(3) and is expected
in other places in OpenSSL.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

The ocsp.h file did not have appropriate guards causing link failures on
Windows.

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

openssl.c and ts.c assign the value of opt_num_rest() to argc, but then
only use the value once.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

All other instances of extract_min_max are checked for an error return,
except this one.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

Also correct the return value from the the "prime" application
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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

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

Various instances of variables being written to, but then never read.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

The state was always set to BIO_CONN_S_OK.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

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