Since they intend to omit gcc, it's more appropriate to simply detect
if there is NDK's clang on PATH, as opposite to requiring to specify it
with CC=clang (and looking for it on PATH).
Also detect NDK version and default to armv7-a for NDK>16.
Address failure to recognize -D__ADNDROID_API__=N in CPPFLAGS.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5613)
Current endianness detection is somewhat opportunistic and can fail
in cross-compile scenario. Since we are more likely to cross-compile
for little-endian now, adjust the default accordingly.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5613)
Occasionally you have to pass -no-integrated-as to clang, but we
consider any -no-option as no-option. Don't touch -no-integrated-as.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5613)
Don't pass a pointer to uninitialized processed value
for BIO_CB_READ and BIO_CB_WRITE
Check the correct cmd code in BIO_callback_ctrl
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5516)
Raw private/public key loading may fail for X25519/X448 if ec has been
disabled.
Also fixed a missing blank line in evppkey.txt resulting in a warning in
the test output.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5664)
If the server is configured to allow early data then we check if the PSK
session presented by the client is available in the cache or not. If it
isn't then this may be a replay and we disallow it. If it is then we allow
it and remove the session from the cache. Note: the anti-replay protection
is not used for externally established PSKs.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5644)
We should only update the session cache when we issue a NewSessionTicket.
These are issued automatically after processing a client certificate.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5644)
Conceptually in TLSv1.3 there can be multiple sessions associated with a
single connection. Each NewSessionTicket issued can be considered a
separate session. We can end up issuing multiple NewSessionTickets on a
single connection at the moment (e.g. in a post-handshake auth scenario).
Each of those issued tickets should have the new_session_cb called, it
should go into the session cache separately and it should have a unique
id associated with it (so that they can be found individually in the
cache).
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5644)
VIA and Shanghai United Investment Co.,Ltd. found Shanghai ZhaoXin,
which is a fabless x86 CPU IC design company. ZhaoXin has issued
ZX-C, ZX-D x86 processors, which have 'Shanghai' CPU vendor id.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5640)
When doing a regression test, it's obvious that the version
test/shlibloadtest is built for will not be the same as the library
version. So we change the test to check for assumed compatibility.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5619)
This is only useful when building shared libraries. This allows us to
run our tests against newer libraries when the time comes. Simply do
this:
OPENSSL_REGRESSION=/other/OpenSSL/build/tree make test
($OPENSSL_REGRESSION *must* be an absolute path)
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5619)
There is a requirements of having access to a live entropy source
which we can't do with the default callbacks. If you need prediction
resistance you need to set up your own callbacks that follow the
requirements of NIST SP 800-90C.
Reviewed-by: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
GH: #5402
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5646)
This commit adds a new api RAND_DRBG_set_defaults() which sets the
default type and flags for new DRBG instances. See also #5576.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5632)
There were a few environment variables that we supported in earlier
Configure versions which got transfered to the %user table. This
change makes sure that we still support them, by simply pre-populating
the corresponding %user entries with those environment values.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5641)
The original intent was that if someone had a "make variable" set in
any kind of way, be it as an environment variable or as an argument to
Configure, we wouldn't allow compiler or linker flags as arguments as
well. That made both of these configurations equivalently impossible:
./Configure target CFLAGS=-foo -lextra
CFLAGS=-foo ./Configure target -lextra
While this makes things look nice and consistent, real world use makes
this hard, as many projects where OpenSSL is a component also set
these variables for other components that use GNU autotools.
Therefore, we need to adapt our Configure accordingly. By
consequence, the two Configure lines above will not be equivalent any
more:
./Configure target CFLAGS=-foo -lextra
This command line will still fail, because the "make variable" was
given as a command line argument. This cannot be a mistake and is
therefore not allowed.
CFLAGS=-foo ./Configure target -lextra
This command line will work, but because there is a linker flag as
a command line argument, the environment (i.e. CFLAGS) is ignored.
That isn't quite consistent with the previous command, but is the old
Configure behavior, before the support for "make variables" was added,
and is therefore the backward compatible behavior.
Fixesgoogle/oss-fuzz#1244
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5641)
In the end, it's more efficient to only have one perl instance (that
loads configdata.pm) dealing with dependency files than running one
(that still loads configdata.pm) for each such file.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5631)
Fixes#4403
This commit moves the internal header file "internal/rand.h" to
<openssl/rand_drbg.h>, making the RAND_DRBG API public.
The RAND_POOL API remains private, its function prototypes were
moved to "internal/rand_int.h" and converted to lowercase.
Documentation for the new API is work in progress on GitHub #5461.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5462)
Instead of just working line by line, we collect all dependencies for
every target and print everything out at the end, with each target
getting a potentially long list of dependencies.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5591)
All dependencies that VC gives us are absolute paths, so we need to
check if some of them are within our source or build tree. We do that
by comparing the start of each dependency with the absolute versions
of our source and build directories.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5591)
It seems that only gcc -MMD produces dependency files that are "sane"
for our needs. For all other methods, some post processing is needed:
- 'makedepend' (Unix) insists that object files are located in the
same spot as the source file.
- 'cl /Zs /showIncludes' (Visual C) has "Note: including file: " where
we'd like to see the object.
- 'CC/DECC' (VMS) insists that the object file is located in the
current directory, i.e. it strips away all directory information.
So far, we've managed this (except for the VMS case) with individual
uncommented perl command lines directly in the build file template.
We're now collecting these diverse hacks into one perl script that
takes an argument to tell what kind of input to expect and that
massages whatever it gets on STDIN and outputs the result on STDOUT.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5591)
It is quite likely for there to be multiple certificates with empty
subjects, which are still distinct because of subjectAltName. Therefore
we allow multiple certificates with an empty Subject even if
unique_subject is set to yes.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5444)
Commit 87e8feca (16 years ago!) introduced a bug where if we are
attempting to insert a cert with a duplicate subject name, and
duplicate subject names are not allowed (which is the default),
then we get an unhelpful error message back (error number 2). Prior
to that commit we got a helpful error message which displayed details
of the conflicting entry in the database.
That commit was itself attempting to fix a bug with the noemailDN option
where we were setting the subject field in the database too early
(before extensions had made any amendments to it).
This PR moves the check for a conflicting Subject name until after all
changes to the Subject have been made by extensions etc.
This also, co-incidentally fixes the ca crashing bug described in issue
5109.
Fixes#5109
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5444)
