- 16 Mar, 2018 5 commits
-
-
Richard Levitte authored
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. Fixes google/oss-fuzz#1244 Reviewed-by:Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5641)
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
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:
-
- 15 Mar, 2018 30 commits
-
-
Richard Levitte authored
Affected symbol names: generate_stateless_cookie_callback verify_stateless_cookie_callback Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5633)
-
Richard Levitte authored
Reviewed-by:
-
Dr. Matthias St. Pierre authored
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)
-
Rich Salz authored
Reviewed-by:
-
Richard Levitte authored
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:
-
Richard Levitte authored
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:
-
Richard Levitte authored
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:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
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:
-
Matt Caswell authored
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:
-
Matt Caswell authored
This reverts commit e505f1e8 . Empty Subjects should be permissible. Reviewed-by:
-
Matt Caswell authored
This reverts commit 1e05c6d0 . Empty subjects should be permissible. Reviewed-by:
-
Matt Caswell authored
Renamed to EVP_PKEY_new_raw_private_key()/EVP_new_raw_public_key() as per feedback. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Include more information about how to create keys for these algorithms. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Previously private and public keys had to be pem encoded to be read by evp_test. This enables us to embed the raw private/public key values in the test file. The algorithm has to support EVP_PKEY_new_private_key() and EVP_PKEY_new_public_key() for this to work. Reviewed-by:
-
Matt Caswell authored
Also adds some documentation for related existing functions/macros Reviewed-by:
-
Matt Caswell authored
Also to use the new EVP_PKEY_new_CMAC_key() Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Not all algorithms will support this, since their keys are not a simple block of data. But many can. Reviewed-by:
-
Sebastian Andrzej Siewior authored
The Debian build system uses a `debian' target which sets CFLAGS and then we have for instance debian-amd64 which inherits from linux-x86_64 and debian [0]. So far so good. Unless there are different suggestions how to do this, I would keep it. However since the target name does not start with `linux', the build system does not enable the afalg engine. So in order to get enabled, I added a `enable => [ "afalgeng" ],' to the generic linux config which sets it explicit (as suggested by Richard Levitte). Having this set, we can check for it instead matching the target name. [0] https://sources.debian.org/src/openssl/1.1.0g-2/Configurations/20-debian.conf/ Signed-off-by:
Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Reviewed-by:
Matt Caswell <matt@openssl.org> Reviewed-by:
-
Matt Caswell authored
In TLSv1.3 the session is not ready until after the end of the handshake when we are constructing the NewSessionTicket. Reviewed-by:
-
Pauli authored
Added two missing OIDs for AES-{128,256}-XTS. Reviewed-by:Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5622)
-
- 14 Mar, 2018 5 commits
-
-
Matt Caswell authored
Reviewed-by:
-
Patrick Steuer authored
Random path generation code in test/recipes/15-test_out_option.t does not work: The code sets rand_path to "/test.pem". I.e. the test will fail as expected for unprivileged user but will pass for root user. Signed-off-by:
Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
