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

This is just in case someone passed an inclusion path with the
configuration, and there are OpenSSL headers from another version
in there.

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

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

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

Since corresponding rule was removed from windows-makefile.tmpl out
of necessity, question popped if it's appropriate to harmonize even
unix-Makefile.tmpl. Note that as long as you work on single directory
'make lib<rary>.a' is effectively equivalent to 'make <dir/ectory>'
prior this modification.

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

Problem with Microsoft lib.exe is that it doesn't *update* modules
in .lib archive, but creates new one upon every invocation. As result
if a source file was updated and nmake was executed, a useless archive
with only one module was created. In other words one has to always
pass all .obj modules on command line, not only recently recompiled.

[This also creates dilemma for directory targets, e.g. crypto\aes,
that were added to simplify every-day life for developer. Since
whole idea behind those targets is to minimize the re-compile time
upon single file modification, the only sensible thing to do is to
omit intended library update.]

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

The previous commit fixed a problem where fragmented alerts would cause an
infinite loop. This commit adds a test for these fragmented alerts.

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

In some situations (such as when we receive a fragment of an alert)
we try to get the next packet but did not mark the current one as read,
meaning that we got the same record back again - leading to an infinite
loop.

Found using the BoringSSL test suite.

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

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

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

There are 3 OPENSSL_API_COMPAT values that are incorrect in the header
files, and one inconsistency between the header and the .c

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

There was some uncertainty about what the code is doing with |$end0|
and whether it was necessary for |$len| to be a multiple of 16 or 96.
Hopefully these added comments make it clear that the code is correct
except for the caveat regarding low memory addresses.

Change-Id: Iea546a59dc7aeb400f50ac5d2d7b9cb88ace9027
Reviewed-on: https://boringssl-review.googlesource.com/7194


Reviewed-by: Adam Langley <agl@google.com>

Signed-off-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

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

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

in EVP_EncryptUpdate and EVP_DecryptUpdate. It is argued that in
general case it's impossible to provide guarantee that partially[!]
overlapping buffers can be tolerated.

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

Re-implemented as suggested by Steve Henson.
Also change ECParameters_print the same way.

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

OBJ_nid2obj() and friends should be treated as const.

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

This reverts commit 82f31fe4

.

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

OBJ_nid2obj() and friends should be treated as const.

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

As of 37258dad

 and the corresponding upstream
change, BN_mod_word may fail, like BN_div_word. Handle this properly. Thanks to
Brian Smith for pointing this out. See BoringSSL's
44bedc348d9491e63c7ed1438db100a4b8a830be.

Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>

GH: #1251

This function returns a tri-state -1 on error. See BoringSSL's
53409ee3d7595ed37da472bc73b010cd2c8a5ffd.

Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>

GH: #1251

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

GH: #1229

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

GH: #1229

Don't print the full list of ciphers as part of the -help output.

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

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

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

RT#4583

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

Fixes openssl/openssl#1236

Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1237)

Found by afl

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

MR: #3013

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

aesni_cbc_hmac_sha256_ctrl() and aesni_cbc_hmac_sha1_ctrl() cleanse the
HMAC key after use, but static int rc4_hmac_md5_ctrl() doesn't.

Fixes an OCAP Audit issue.

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

This includes the newly added HMAC_CTX_get_md().

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

As a result of opaque HMAC_CTX apps need a getter for the HMAC_CTX md.

GitHub Issue #1152

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

tag2nbyte had -1 at 18th position, but underlying ASN1_mbstring_copy
supports NumericString. tag2nbyte is also used in do_print_ex which will
not be broken by setting 1 at 18th position of tag2nbyte

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

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

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

with "make install -j8" it happens very often that two or more make
instances are creating the same directory in parallel. As a result one
instace creates the directory and second mkdir fails because the
directory exists already (but it did not while testing for it earlier).

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1204)

Code and tests by Steve.

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

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

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

MR: #2986