gcc 4.6 (arguably erroneously) warns about our use of 'free' as
the name of a function parameter, when --strict-warnings is enabled:
crypto/x509/x509_meth.c: In function 'X509_LOOKUP_meth_set_free':
crypto/x509/x509_meth.c:61:12: error: declaration of 'free' shadows a global declaration [-Werror=shadow]
cc1: all warnings being treated as errors
make[1]: *** [crypto/x509/x509_meth.o] Error 1
(gcc 4.8 is fine with this code, as are newer compilers.)
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6991)
CRYPTO_atomic_read was added with intention to read statistics counters,
but readings are effectively indistinguishable from regular load (even
in non-lock-free case). This is because you can get out-dated value in
both cases. CRYPTO_atomic_write was added for symmetry and was never used.
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/6883)
Relax memory_order on counter decrement itself, because mutable
members of the reference-counted structure should be visible on all
processors independently on counter. [Even re-format and minimize
dependency on other headers.]
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/6900)
The TLSv1.4 tolerance test wasn't testing what we thought it was.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6741)
If application explicitly calls CONF_modules_load_file() the SSL
conf module will be initialized twice and the module data would leak.
We need to free it before initializing it again.
Fixes#6835
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6948)
The logs are usually not looked at, and when they are it's almost
always after they've completed and returned a status. That being
the case, "progress" output is useless if it's always seen after
the fact.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6928)
Originally fopen(3) was called from bio/bss_file.c, which performed the
aliasing. Then fopen(3) was moved to o_fopen.c, while "magic" definition
was left behind. It's still useful on 32-bit platforms, so pull it to
o_fopen.c.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6596)
This allows the original path to be displayed when it's shown
to be invalid, so the user can relate without question.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6925)
Extra slashes in paths are permissible in Unix-like platforms...
however, when compared with the result from 'which', which returns
canonical paths, the comparison might fail even though the compared
paths may be equivalent. We make the NDK path canonical internally to
ensure the equivalence compares as equal, at least for the most
trivial cases.
Fixes#6917
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6924)
Since 0.9.7, all i2d_ functions were documented to allocate an output
buffer if the user didn't provide one, under these conditions (from
the 1.0.2 documentation):
For OpenSSL 0.9.7 and later if B<*out> is B<NULL> memory will be
allocated for a buffer and the encoded data written to it. In this
case B<*out> is not incremented and it points to the start of the
data just written.
i2d_ASN1_OBJECT was found not to do this, and would crash if a NULL
output buffer was provided.
Fixes#6914
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/6918)
Commit 8839324 removed some NULL checks from the stack code. This caused
a no-comp build to fail in the client and server fuzzers.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6893)
This reverts commit 8839324450.
Removing these checks changes the behaviour of the API which is not
appropriate for a minor release. This also fixes a failure in the
fuzz tests when building with no-comp.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6895)
A client that has fallen back could detect an inappropriate fallback if
the TLSv1.3 downgrade protection sentinels are present.
Fixes#6756
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6894)
Test that a server can handle an unecrypted alert when normally the next
message is encrypted.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6887)
At certain points in the handshake we could receive either a plaintext or
an encrypted alert from the client. We should tolerate both where
appropriate.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6887)
If we sent early_data and then received back an HRR, the enc_write_ctx
was stale resulting in errors if an alert needed to be sent.
Thanks to Quarkslab for reporting this.
In any case it makes little sense to encrypt alerts using the
client_early_traffic_secret, so we add special handling for alerts sent
after early_data. All such alerts are sent in plaintext.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6887)
Under certain error conditions a call to SSLfatal could accidently be
missed.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6872)
In 38eca7fed0 a new check for the pem_str member of the entries of the
ASN1 method table was introduced. Because the test condition was split
into two TEST_true(...) conditions, the test outputs error diagnostics
for all entries which have pem_str != NULL. This commit joins the two
test conditions into a single condition.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6888)
Also add build-time errors to keep them in sync.
Thanks to GitHub user YuDudysheva for reporting this.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6874)
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6870)
Rationale is that it wasn't providing accurate statistics anyway.
For statistics to be accurate CRYPTO_get_alloc_counts should acquire
a lock and lock-free additions should not be an option.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6786)
Goal here is to facilitate writing "thread-opportunistic" code that
withstands Thread Sanitizer's scrutiny. "Thread-opportunistic" is when
exact result is not required, e.g. some statistics, or execution flow
doesn't have to be unambiguous.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6786)
Checks are left in OPENSSL_sk_shift, OPENSSL_sk_pop and OPENSSL_sk_num.
This is because these are used as "opportunistic" readers, pulling
whatever datai, if any, set by somebody else. All calls that add data
don't check for stack being NULL, because caller should have checked
if stack was actually created.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6860)
In some cases it's about redundant check for return value, in some
cases it's about replacing check for -1 with comparison to 0.
Otherwise compiler might generate redundant check for <-1. [Even
formatting and readability fixes.]
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6860)
Documentation says "at most B<len> bytes will be written", which
formally doesn't prohibit zero. But if zero B<len> was passed, the
call to memcpy was bound to crash.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6860)
The CRYPTO_memcmp test isn't testing the test framework.
It would seem to better belong in the sanity tests.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6878)
In some scenarios the connection could fail without an alert being sent.
This causes a later assertion failure.
Thanks to Quarkslab for reporting this.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/6852)
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5935)
Fixes#6800
Replaces #5418
This commit reverts commit 7876dbffce and moves the check for a
zero-length input down the callstack into sha3_update().
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/6838)
