- 23 Feb, 2018 16 commits
-
-
Rich Salz authored
Reviewed-by:
Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5439)
-
Bernd Edlinger authored
Reviewed-by:
Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5426)
-
Bernd Edlinger authored
Reviewed-by:
Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5434)
-
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:
-
- 22 Feb, 2018 11 commits
-
-
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:
Richard Levitte <levitte@openssl.org> 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:
-
- 21 Feb, 2018 13 commits
-
-
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:
-
Matt Caswell authored
We can't add NULL data into a hash Reviewed-by:
-
Matt Caswell authored
When the proxy re-encrypted a TLSv1.3 record it was adding a spurious byte onto the end. This commit removes that. The "extra" byte was intended to be the inner content type of the record. However, TLSProxy was actually adding the original encrypted data into the record (which already has the inner content type in it) and then adding the spurious additional content type byte on the end (and adjusting the record length accordingly). It is interesting to look at why this didn't cause a failure: The receiving peer first attempts to decrypt the data. Because this is TLSProxy we always use a GCM based ciphersuite with a 16 byte tag. When we decrypt this it actually gets diverted to the ossltest engine. All this does is go through the motions of encrypting/decrypting but just passes back the original data. Crucially it will never fail because of a bad tag! The receiving party thinks the spurious additional byte is part of the tag and the ossltest engine ignores it. This means the data that gets passed back to the record layer still has an additional spurious byte on it - but because the 16 byte tag has been removed, this is actually the first byte of the original tag. Again because we are using ossltest engine we aren't actually creating "real" tags - we only ever emit 16, 0 bytes for the tag. So the spurious additional byte always has the value 0. The TLSv1.3 spec says that records can have additional 0 bytes on the end of them - this is "padding". So the record layer interprets this 0 byte as padding and strips it off to end up with the originally transmitted record data - which it can now process successfully. Reviewed-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> (Merged from https://github.com/openssl/openssl/pull/5370)
-
Richard Levitte authored
The internals test programs access header files that aren't guarded by the public __DECC_INCLUDE_PROLOGUE.H and __DECC_INCLUDE_EPILOGUE.H files, and therefore have no idea what the naming convention is. Therefore, we need to specify that explicitely in the internals test programs, since they aren't built with the same naming convention as the library they belong with. Reviewed-by:
-
Andy Polyakov authored
So far check for availability of Win32::API served as implicit check for $^O being MSWin32. Reportedly it's not safe assumption, and check for MSWin32 has to be explicit. Reviewed-by:
-
