This project is mirrored from https://github.com/openssl/openssl.git.
Pull mirroring failed .
Last successful update .
Last successful update .
- 08 Dec, 2020 9 commits
-
-
Matt Caswell authored
Reviewed-by:Richard Levitte <levitte@openssl.org>
-
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
If you have a CHOICE type that it must use explicit tagging - otherwise the template is invalid. We add tests for this. Reviewed-by:Tomas Mraz <tmraz@fedoraproject.org>
-
Matt Caswell authored
Based on a boringssl test contributed by David Benjamin Reviewed-by: -
Matt Caswell authored
It never makes sense for multi-string or CHOICE types to have implicit tagging. If we have a template that uses the in this way then we should immediately fail. Thanks to David Benjamin from Google for reporting this issue. Reviewed-by: -
Matt Caswell authored
It never makes sense for multi-string or CHOICE types to use implicit tagging since the content would be ambiguous. It is an error in the template if this ever happens. If we detect it we should stop parsing. Thanks to David Benjamin from Google for reporting this issue. Reviewed-by: -
Matt Caswell authored
If a GENERAL_NAME field contained EdiPartyName data then it was incorrectly being handled as type "other". This could lead to a segmentation fault. Many thanks to David Benjamin from Google for reporting this issue. CVE-2020-1971 Reviewed-by: -
Matt Caswell authored
EDIPartyName has 2 fields that use a DirectoryString. However they were marked as implicit tagging - which is not correct for a CHOICE type. Additionally the partyName field was marked as Optional when, according to RFC5280 it is not. Many thanks to github user @filipnavara for reporting this issue. Also to David Benjamin from Google who independently identified and reported it. Fixes #6859 Reviewed-by:
-
- 04 Dec, 2020 1 commit
-
-
Richard Levitte authored
Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13605)
-
- 03 Dec, 2020 2 commits
-
-
Dr. David von Oheimb authored
The certificate path validation procedure specified in RFC 5280 does not include checking the validity period of the trusted (root) certificate. Still it is common good practice to perform this check. Also OpenSSL did this until version 1.1.1h, yet commit e2590c3a accidentally killed it. The current commit restores the previous behavior. It also removes the cause of that bug, namely counter-intuitive design of the internal function check_issued(), which was complicated by checks that actually belong to some other internal function, namely find_issuer(). Moreover, this commit adds a regression check and proper documentation of the root cert validity period check feature, which had been missing so far. Fixes #13471 Reviewed-by:
-
Stuart Carnie authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by:
-
- 02 Dec, 2020 2 commits
-
-
Benjamin Kaduk authored
This code started off as a copy of ssl3_write_bytes(), and the comment was not updated with the implementation. Reported by yangyangtiantianlonglong in #13518 Reviewed-by:
Shane Lontis <shane.lontis@oracle.com> Reviewed-by:
-
Dr. David von Oheimb authored
Reviewed-by:
-
- 01 Dec, 2020 1 commit
-
-
Ard Biesheuvel authored
ARM Cortex-A57 and Cortex-A72 cores running in 32-bit mode are affected by silicon errata #1742098 [0] and #1655431 [1], respectively, where the second instruction of a AES instruction pair may execute twice if an interrupt is taken right after the first instruction consumes an input register of which a single 32-bit lane has been updated the last time it was modified. This is not such a rare occurrence as it may seem: in counter mode, only the least significant 32-bit word is incremented in the absence of a carry, which makes our counter mode implementation susceptible to these errata. So let's shuffle the counter assignments around a bit so that the most recent updates when the AES instruction pair executes are 128-bit wide. [0] ARM-EPM-049219 v23 Cortex-A57 MPCore Software Developers Errata Notice [1] ARM-EPM-012079 v11.0 Cortex-A72 MPCore Software Developers Errata Notice Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by:
Paul Dale <paul.dale@oracle.com> Reviewed-by:
-
- 27 Nov, 2020 1 commit
-
-
ihsinme authored
CLA: trivial Reviewed-by:
-
- 11 Nov, 2020 2 commits
-
-
Pauli authored
Fixes #13361 Reviewed-by:
-
Dmitry Belyavskiy authored
Fixes #13082 Reviewed-by:
-
- 05 Nov, 2020 1 commit
-
-
T.Yanagisawa authored
CLA: trivial Correct right shift to left shift. Pseudo code `a&=~((~0)>>n)` means "get higher n-bits of a", but actually crypto lib gives lower n-bits. Reviewed-by:
-
- 29 Oct, 2020 3 commits
-
-
Benjamin Kaduk authored
The handling for the SCSVs was the same as for regular ciphers; just merge them into the same table-driven handler. Reviewed-by:
-
hklaas authored
Return immediately on matched cipher. Without this patch the code only breaks out of the inner for loop, meaning for a matched TLS13 cipher the code will still loop through 160ish SSL3 ciphers. CLA: trivial Reviewed-by:
Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/13280)
-
Ard Biesheuvel authored
PAC pointer authentication signs the return address against the value of the stack pointer, to prevent stack overrun exploits from corrupting the control flow. However, this requires that the AUTIASP is issued with SP holding the same value as it held when the PAC value was generated. The Poly1305 armv8 code got this wrong, resulting in crashes on PAC capable hardware. Reviewed-by:
-
- 26 Oct, 2020 2 commits
-
-
Matt Caswell authored
We were missing a call to SSLfatal. A comment claimed that we had already called it - but that is incorrect. Reviewed-by:
-
André Klitzing authored
This unifies the behaviour of a single certificate with an unknown CA certificate with a self-signed certificate. The user callback can mask that error to retrieve additional error information. So the user application can decide to abort the connection instead to be forced by openssl. This change in behaviour is backward compatible as user callbacks who don't want to ignore UNABLE_TO_VERIFY_LEAF_SIGNATURE will still abort the connection by default. CLA: trivial Fixes #11297 Reviewed-by:
David von Oheimb <david.von.oheimb@siemens.com> Reviewed-by:
-
- 22 Oct, 2020 1 commit
-
-
Romain Geissler authored
Cherry-pick of https://github.com/openssl/openssl/pull/13056 for branch 1.1.1. Tested against the release 1.1.1h Reviewed-by:
-
- 21 Oct, 2020 1 commit
-
-
simplelins authored
Fixes #10638 Fixes #13188 Fixes a bug for aarch64 bigendian with instructions 'st1' and 'ld1' on AES-GCM mode. CLA: trivial (cherry picked from commit bc8b648f) Reviewed-by:
-
- 20 Oct, 2020 2 commits
-
-
xuyunjia authored
Reviewed-by:
-
Tomas Mraz authored
Fixes regression from 7844f3c7Reviewed-by:
-
- 16 Oct, 2020 2 commits
-
-
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
The security operation SSL_SECOP_TMP_DH is defined to take an EVP_PKEY in the "other" parameter: /* Temporary DH key */ # define SSL_SECOP_TMP_DH (7 | SSL_SECOP_OTHER_PKEY) In most places this is what is passed. All these places occur server side. However there is one client side call of this security operation and it passes a DH object instead. This is incorrect according to the definition of SSL_SECOP_TMP_DH, and is inconsistent with all of the other locations. Our own default security callback, and the debug callback in the apps, never look at this value and therefore this issue was never noticed previously. In theory a client side application could be relying on this behaviour and could be broken by this change. This is probably fairly unlikely but can't be ruled out. Reviewed-by:
-
- 15 Oct, 2020 1 commit
-
-
Akshit Akhoury authored
CLA: trivial Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> Reviewed-by:
-
- 14 Oct, 2020 1 commit
-
-
Yury Is authored
Several embedded toolchains may provide dummy implemented getentropy() function which always returns -1 and sets errno to the ENOSYS. As a result the function SSL_CTX_new() fails to create a new context. Fixes #13002 Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/13112)
-
- 13 Oct, 2020 1 commit
-
-
Ikko Ashimine authored
orignal -> original CLA: trivial Reviewed-by:
-
- 06 Oct, 2020 2 commits
-
-
Benny Baumann authored
Reviewed-by:
-
Benny Baumann authored
Reviewed-by:
-
- 03 Oct, 2020 1 commit
-
-
drgler authored
Since glibc 2.8, these defines like `NI_MAXHOST` are exposed only if suitable feature test macros are defined, namely: _GNU_SOURCE, _DEFAULT_SOURCE (since glibc 2.19), or _BSD_SOURCE or _SVID_SOURCE (before glibc 2.19), see GETNAMEINFO(3). CLA: trivial Fixes #13049 Reviewed-by:
-
- 22 Sep, 2020 4 commits
-
-
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Reviewed-by: -
Matt Caswell authored
Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
