The logic with how 'ok' was calculated didn't quite convey what's "ok",
so the logic is slightly redone to make it less confusing.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(cherry picked from commit 06affe3d)

Filled in lots of return value checks that were missing the GOST engine, and
added appropriate error handling.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 8817e2e0)

Fix miscellaneous NULL pointer derefs in the sureware engine.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 7b611e5f)

Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 7be6bc68)

This addresses

- request for improvement for faster key setup in RT#3576;
- clearing registers and stack in RT#3554 (this is more of a gesture to
see if there will be some traction from compiler side);
- more commentary around input parameters handling and stack layout
(desired when RT#3553 was reviewed);
- minor size and single block performance optimization (was lying around);

Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 23f6eec7)

Disable loop checking when we retry verification with an alternative path.
This fixes the case where an intermediate CA is explicitly trusted and part
of the untrusted certificate list. By disabling loop checking for this case
the untrusted CA can be replaced by the explicitly trusted case and
verification will succeed.

Signed-off-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit e5991ec5

)

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

the X509_V_FLAG_NO_ALT_CHAINS flag.

Conflicts:
	doc/apps/cms.pod
	doc/apps/ocsp.pod
	doc/apps/s_client.pod
	doc/apps/s_server.pod
	doc/apps/smime.pod
	doc/apps/verify.pod

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

X509_V_FLAG_NO_ALT_CHAINS flag. Using this option means that when building
certificate chains, the first chain found will be the one used. Without this
flag, if the first chain found is not trusted then we will keep looking to
see if we can build an alternative chain instead.

Conflicts:
	apps/cms.c
	apps/ocsp.c
	apps/s_client.c
	apps/s_server.c
	apps/smime.c
	apps/verify.c

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

behaviour will force behaviour as per previous versions of OpenSSL

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

valid. However the issuer of the leaf, or some intermediate cert is in fact
in the trust store.

When building a trust chain if the first attempt fails, then try to see if
alternate chains could be constructed that are trusted.

RT3637
RT3621

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

Fix bug where i2c_ASN1_INTEGER mishandles zero if it is marked as
negative.

Thanks to Huzaifa Sidhpurwala <huzaifas@redhat.com> and
Hanno Böck <hanno@hboeck.de> for reporting this issue.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit a0eed48d)

A 0-length ciphers list is never permitted. The old code only used to
reject an empty ciphers list for connections with a session ID. It
would later error out on a NULL structure, so this change just moves
the alert closer to the problem source.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 3ae91cfb)

The disabled set of -Weverything is hard to maintain across versions.
Use -Wall -Wextra but also document other useful warnings that currently trigger.

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

Reviewed-by: Matt Caswell <gitlab@openssl.org>

Reported by Hanno Böck <hanno@hboeck.de>
PR#3800

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit c4137b5e)

Reported by Hanno Böck <hanno@hboeck.de>

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 111b60be)

If OpenSSL is configured with no-tlsext then ssl_get_prev_session can read
past the end of the ClientHello message if the session_id length in the
ClientHello is invalid. This should not cause any security issues since the
underlying buffer is 16k in size. It should never be possible to overrun by
that many bytes.

This is probably made redundant by the previous commit - but you can never be
too careful.

With thanks to Qinghao Tang for reporting this issue.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 5e0a80c1)

The ClientHello processing is insufficiently rigorous in its checks to make
sure that we don't read past the end of the message. This does not have
security implications due to the size of the underlying buffer - but still
needs to be fixed.

With thanks to Qinghao Tang for reporting this issue.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit c9642eb1ff79a30e2c7632ef8267cc34cc2b0d79)

It would set gen->d.dirn to a freed pointer in case X509V3_NAME_from_section
failed.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 8ec5c5dd)

Reviewed-by: Viktor Dukhovni <openssl-users@dukhovni.org>
(cherry picked from commit f49baeff)

While *pval is usually a pointer in rare circumstances it can be a long
value. One some platforms (e.g. WIN64) where
sizeof(long) < sizeof(ASN1_VALUE *) this will write past the field.

*pval is initialised correctly in the rest of ASN1_item_ex_new so setting it
to NULL is unecessary anyway.

Thanks to Julien Kauffmann for reporting this issue.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit f617b496)

Conflicts:
	crypto/asn1/tasn_new.c

PR#3789

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 7a317fa0)

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 9fdbc9df)

Since source reformat, we ended up with some error reason string
definitions that spanned two lines.  That in itself is fine, but we
sometimes edited them to provide better strings than what could be
automatically determined from the reason macro, for example:

    {ERR_REASON(SSL_R_NO_GOST_CERTIFICATE_SENT_BY_PEER),
     "Peer haven't sent GOST certificate, required for selected ciphersuite"},

However, mkerr.pl didn't treat those two-line definitions right, and
they ended up being retranslated to whatever the macro name would
indicate, for example:

    {ERR_REASON(SSL_R_NO_GOST_CERTIFICATE_SENT_BY_PEER),
     "No gost certificate sent by peer"},

Clearly not what we wanted.  This change fixes this problem.

Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 2cfdfe09)

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 37d92b1b)

The macros BSWAP4 and BSWAP8 have statetemnt expressions
implementations that use local variable names that shadow variables
outside the macro call, generating warnings like this

e_aes_cbc_hmac_sha1.c:263:14: warning: declaration shadows a local variable
      [-Wshadow]
    seqnum = BSWAP8(blocks[0].q[0]);
             ^
../modes/modes_lcl.h:41:29: note: expanded from macro 'BSWAP8'
                            ^
e_aes_cbc_hmac_sha1.c:223:12: note: previous declaration is here
    size_t ret = 0;
           ^

Have clang be quiet by modifying the macro variable names slightly
(suffixing them with an underscore).

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 2da2a434)

We use GNU statement expressions in crypto/md32_common.h, surrounded
by checks that GNU C is indeed used to compile.  It seems that clang,
at least on Linux, pretends to be GNU C, therefore finds the statement
expressions and then warns about them.

The solution is to have clang be quiet about it.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 04958e84)

ebcdic.c:284:7: warning: ISO C requires a translation unit to contain at least one
      declaration [-Wempty-translation-unit]
      ^
1 warning generated.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit c25dea53)

There is no indication that the timing differences are exploitable in
OpenSSL, and indeed there is some indication (Usenix '14) that they
are too small to be exploitable. Nevertheless, be careful and apply
the same countermeasures as in s3_srvr.c

Thanks to Nimrod Aviram, Sebastian Schinzel and Yuval Shavitt for
reporting this issue.

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

Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 7eeeb49e)

Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit be5a87a1)

ARM has optimized Cortex-A5x pipeline to favour pairs of complementary
AES instructions. While modified code improves performance of post-r0p0
Cortex-A53 performance by >40% (for CBC decrypt and CTR), it hurts
original r0p0. We favour later revisions, because one can't prevent
future from coming. Improvement on post-r0p0 Cortex-A57 exceeds 50%,
while new code is not slower on r0p0, or Apple A7 for that matter.

[Update even SHA results for latest Cortex-A53.]

Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 94376ccc)

RFC5915 requires the use of the I2OSP primitive as defined in RFC3447
for storing an EC Private Key. This converts the private key into an
OCTETSTRING and retains any leading zeros. This commit ensures that those
leading zeros are present if required.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(cherry picked from commit 30cd4ff2)

Conflicts:
	crypto/ec/ec_asn1.c

Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit b06a6f7cc44baa0c17207a8f72c4ac360be7b555)

if CAfile or CApath were also supplied and successfully loaded first.

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

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

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

create an HMAC

Inspired by BoringSSL commit 2fe7f2d0d9a6fcc75b4e594eeec306cc55acd594

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

Conflicts:
	crypto/hmac/hmac.c

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

Ensure all calls to RAND_bytes and RAND_pseudo_bytes have their return
value checked correctly

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