- Mar 15, 2018
-
-
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:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5591)
-
Matt Caswell authored
Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5623)
-
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:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5621)
-
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)
-
- Mar 14, 2018
-
-
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:
-
Matt Caswell authored
A place in clienthellotest was missed in converting to the new mechanism for configuration of TLSv1.3 ciphersuites. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
With the current mechanism, old cipher strings that used to work in 1.1.0, may inadvertently disable all TLSv1.3 ciphersuites causing connections to fail. This is confusing for users. In reality TLSv1.3 are quite different to older ciphers. They are much simpler and there are only a small number of them so, arguably, they don't need the same level of control that the older ciphers have. This change splits the configuration of TLSv1.3 ciphers from older ones. By default the TLSv1.3 ciphers are on, so you cannot inadvertently disable them through your existing config. Fixes #5359 Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5604)
-
Matt Caswell authored
As per the latest text in TLSv1.3 draft-26 Reviewed-by:
-
Matt Caswell authored
As of TLSv1.3 draft-25 the record header data must be used as AAD Reviewed-by:
-
Richard Levitte authored
We have '--strict-warnings' for this kind of stuff... also, user flags are added last, so this overrides any warning supression --strict-warnings may put in place (for good reasons). Fixes #5609 Reviewed-by:
-
- Mar 13, 2018
-
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
... also, name it with "-$$" added instead of ".$$" Reviewed-by:
-
