- Feb 24, 2018
-
-
Andy Polyakov authored
Reviewed-by:
Matt Caswell <matt@openssl.org> Reviewed-by:
Rich Salz <rsalz@openssl.org> Reviewed-by:
Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5449)
-
Andy Polyakov authored
As it turns out gcc -pedantic doesn't seem to consider __uint128_t as non-standard, unlike __int128 that is. Fix even MSVC warnings in curve25519.c. Reviewed-by:
-
Andy Polyakov authored
SPARC condition in __SIZEOF_INT128__==16 is rather performance thing than portability. Even though compiler advertises int128 capability, corresponding operations are inefficient, because they are not directly backed by instruction set. Reviewed-by:
-
Andy Polyakov authored
Reviewed-by:
-
- Feb 23, 2018
-
-
Rich Salz authored
Reviewed-by:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5439)
-
Bernd Edlinger authored
Reviewed-by:
-
Bernd Edlinger authored
Reviewed-by:
-
Richard Levitte authored
[extended tests] Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Pauli authored
The return at the end isn't reachable. Reviewed-by:
-
- Feb 22, 2018
-
-
Richard Levitte authored
The reason for this is that some of the C flags affect built in macros that we may depend on. Reviewed-by:
-
Rich Salz authored
Reviewed-by:
-
Steve Linsell authored
When compiling with -Wall on a machine with an old compiler it gives a false positive that the dc variable which is a structure of type DISPLAY_COLUMNS could be used uninitialised. In fact the dc variable's members will always get set in the case it is used, otherwise it is left uninitialised. This fix just causes the dc variable's members to always get initialised to 0 at declaration, so the false positive will not get flagged. Reviewed-by:
-
Per Sandström authored
CLA: trivial fix typo: EC_point2buf => EC_POINT_point2buf Reviewed-by:
Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
The new message is geared toward issue reports Reviewed-by:
-
Richard Levitte authored
Reviewed-by:
-
Richard Levitte authored
No more special casing for that one, and this means it gets displayed by 'perl configdata.pm --make-variables' among all the others. Reviewed-by:
-
Richard Levitte authored
If the configured value is the empty string, give them a sane default. Otherwise, give them the configured value prefix with $(CROSS_COMPILE) Reviewed-by:
-
Richard Levitte authored
It was inconsistent to see this specific command have '$(CROSS_COMPILE)' in its value when no other command did. Reviewed-by:
-
Richard Levitte authored
Specifically, the specific perl that was used to run Configure Reviewed-by:
-
- Feb 21, 2018
-
-
Kurt Roeckx authored
Reviewed-by:
Paul Dale <paul.dale@oracle.com> GH: #5400
-
Kurt Roeckx authored
Reviewed-by: -
Viktor Dukhovni authored
Thanks to Norm Green for reporting this issue. Signed-off-by:
-
EasySec authored
Reviewed-by:
Tim Hudson <tjh@openssl.org> Reviewed-by:
-
Pavel Kopyl authored
The memory pointed to by the 'push' is freed by the X509_NAME_ENTRY_free() in do_body(). The second time it is referenced to (indirectly) in certify_cert:X509_REQ_free(). Reviewed-by:
-
Pavel Kopyl authored
X509v3_add_ext: free 'sk' if the memory pointed to by it was malloc-ed inside this function. X509V3_EXT_add_nconf_sk: return an error if X509v3_add_ext() fails. This prevents use of a freed memory in do_body:sk_X509_EXTENSION_num(). Reviewed-by:
-
Samuel Weiser authored
Replaced variable-time GCD with consttime inversion to avoid side-channel attacks on RSA key generation Reviewed-by:
Kurt Roeckx <kurt@roeckx.be> (Merged from https://github.com/openssl/openssl/pull/5161)
-
Matt Caswell authored
This could in theory result in an overread - but due to the over allocation of the underlying buffer does not represent a security issue. Thanks to Fedor Indutny for reporting this issue. Reviewed-by:
Ben Kaduk <kaduk@mit.edu> (Merged from https://github.com/openssl/openssl/pull/5414)
-
Matt Caswell authored
[extended tests] Reviewed-by:
-
