The reason for this is that some of the C flags affect built in macros
that we may depend on.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5436)
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: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5337)
CLA: trivial
fix typo:
EC_point2buf => EC_POINT_point2buf
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5367)
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: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)
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: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)
It was inconsistent to see this specific command have
'$(CROSS_COMPILE)' in its value when no other command did.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5247)
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Dr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
GH: #5400
Thanks to Norm Green for reporting this issue.
Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5423)
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: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4698)
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: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4698)
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/5161)
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: Rich Salz <rsalz@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5414)
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)
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: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5425)
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: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5416)
Currently it's limited to 64-bit platforms only as minimum radix
expected in assembly is 2^51.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5408)
3 least significant bits of the input scalar are explicitly cleared,
hence swap variable has fixed value [of zero] upon exit from the loop.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/5408)
