- 19 Apr, 2019 18 commits
-
-
Matt Caswell authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8780)
-
Matt Caswell authored
Reviewed-by:
Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8700)
-
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
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
We also lay the ground work for various of other the basic AES ciphers. Reviewed-by:
-
Matt Caswell authored
Reviewed-by:
-
Richard Levitte authored
The comparator further down the call stack doesn't tolerate NULL, so if we got that as input, use the empty string. Reviewed-by:
-
Richard Levitte authored
OPENSSL_LH_flush() frees the linked lists for each slot, but didn't set the list head to NULL after doing so, with the result that an operation that affects these lists is likely to cause a crash. Reviewed-by:
-
Richard Levitte authored
ossl_method_store_cache_get() and ossl_method_store_cache_set() were called with a NULL argument for store, which means no caching is done. Give them a real store instead. Also, increment the refcount when we do get a method out of the cache. Reviewed-by:
-
- 18 Apr, 2019 2 commits
-
-
Richard Levitte authored
|str| was used for multiple conflicting purposes. When using '-strictpem', it's used to uniquely hold a reference to the loaded payload. However, when using '-strparse', |str| was re-used to hold the position from where to start parsing. So when '-strparse' and '-strictpem' are were together, |str| ended up pointing into data pointed at by |at|, and was yet being freed, with the result that the payload it held a reference to became a memory leak, and there was a double free conflict when both |str| and |at| were being freed. The situation is resolved by always having |buf| hold the pointer to the file data, and always and only use |str| to hold the position to start parsing from. Now, we only need to free |buf| properly and not |str|. Fixes #8752 Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> (Merged from https://github.com/openssl/openssl/pull/8753)
-
Simo Sorce authored
Signed-off-by:
Simo Sorce <simo@redhat.com> Reviewed-by:
Richard Levitte <levitte@openssl.org> Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8774)
-
- 17 Apr, 2019 4 commits
-
-
Andy Polyakov authored
The change is triggered by ThunderX2 where 3+1 was slower than scalar code path, but it helps all processors [to handle <512 inputs]. Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
Pauli authored
Reviewed-by:
-
- 16 Apr, 2019 5 commits
-
-
Tomas Mraz authored
Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by:
-
Tomas Mraz authored
Reviewed-by:
-
Tomas Mraz authored
Reviewed-by:
-
Bernd Edlinger authored
Reviewed-by:
-
Tomas Mraz authored
Reviewed-by:
-
- 15 Apr, 2019 4 commits
-
-
Kurt Roeckx authored
The callback should be called with 1 when a Miller-Rabin round marked the candidate as probably prime. Reviewed-by: -
Richard Levitte authored
The clang documentation in all sanitizers we currently use says this: When linking shared libraries, the {flavor}Sanitizer run-time is not linked, so -Wl,-z,defs may cause link errors (don’t use it with {flavor}Sanitizer) (in our case, {flavor} is one of Address, Memory, or UndefinedBehavior) Therefore, we turn off that particular flag specifically when using the sanitizers. Fixes #8735 Reviewed-by: -
Richard Levitte authored
Forward declare the dispatched functions using typedefs from core_numbers.h. This will ensure that they have correct signatures. Reviewed-by:
-
Richard Levitte authored
This allows the provider digest_final operation to check that it doesn't over-run the output buffer. The EVP_DigestFinal_ex function doesn't take that same parameter, so it will have to assume that the user provided a properly sized buffer, but this leaves better room for future enhancements of the public API. Reviewed-by:
-
- 14 Apr, 2019 2 commits
-
-
David Benjamin authored
The rep parameter takes an int in C, but the assembly implementation looks at the upper bits. While it's unlikely to happen here, where all calls pass a constant, in other scenarios x86_64 compilers will leave arbitrary values in the upper half. Fix this by making the C prototype match the assembly. (This aspect of the calling convention implies smaller-than-word arguments in assembly functions should be avoided. There are far fewer things to test if everything consistently takes word-sized arguments.) This was found as part of ABI testing work in BoringSSL. Reviewed-by:
-
Bernd Edlinger authored
This happens in ec_key_simple_check_key and EC_GROUP_check. Since the the group order is not a secret scalar, it is unnecessary to use coordinate blinding. Fixes: #8731 Reviewed-by:
-
- 12 Apr, 2019 5 commits
-
-
Joshua Lock authored
A couple of minor tweaks to match the style introduced in #7854: - BIO_connect: remove line break to make more grep friendly - SSL_CTX_new: harmoise the format of the HISTORY section Reviewed-by:
-
Joshua Lock authored
SEE ALSO before HISTORY is the more common pattern in OpenSSL manual pages and seems to be the prevalent order based on sampling my system manual pages. Fixes #8631 Reviewed-by:
-
Joshua Lock authored
Check that the HISTORY section is located after the SEE ALSO section, this is a much more frequent order in OpenSSL manual pages (and UNIX manual pages in general). Also check that SEE ALSO comes after EXAMPLES, so that the tool can ensure the correct manual section sequence. Reviewed-by:
-
Joshua Lock authored
Change to check_section_location(), a generic function to ensure that section SECTION appears before section BEFORE in the man pages. Reviewed-by:
-
Matt Caswell authored
These undocumented functions were never integrated into the EVP layer and implement the AES Infinite Garble Extension (IGE) mode and AES Bi-directional IGE mode. These modes were never formally standardised and usage of these functions is believed to be very small. In particular AES_bi_ige_encrypt() has a known bug. It accepts 2 AES keys, but only one is ever used. The security implications are believed to be minimal, but this issue was never fixed for backwards compatibility reasons. Reviewed-by:
-
