Recently ci on master has been failing:
https://github.com/openssl/openssl/actions/runs/14234051502/job/39919663876
Its occuring because the s390 gcc compiler is complaining about various
functions attempting to write past the end of an array.
However, I can find no case in which we actually do so in this case.
The problem resolves when we either:
1) Disable the stringop-overflow warning
or
2) disable all loop unrolling optimizations with fno-loop-nest-optimize
Given that asan doesn't report any out of bounds errors on s390 when
built with case (1), and case (2) can be a significant performance hit,
coupled with the fact that gcc on any other platform avoids the same
issue (s390 is stuck on gcc 12, instead of gcc 16 where the other
platforms are), I think the right thing to do is just disable the
warning here
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27253)
- Add information about OpenSSL 3.5 server-side QUIC support
- Include specific command instructions for running the QUIC server example
- Explicitly note that s_server does NOT support QUIC
- Fix documentation formatting (trailing spaces and blank lines around code blocks)
Signed-off-by: Samson S. Kolge <eglok1980@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27230)
The SHA-256 (SZ=4) and SHA-512 (SZ=8) dispatcher paths have been
separated while keeping the SHA-256 path unmodified.
Due to early constraints in register availability, two 32-bit
`OPENSSL_ia32cap_P` reads have been coalesced into one. As a
consequence, several bit positions used in feature checks have gained a
32 bits offset.
Replaced `test` with `bt` to allow use of 64-bit immediate indices in
CPUID feature checks.
Split the SHA512 BMI2+AVX2+BMI1 dispatcher branch into:
- AVX2+SHA512: high priority, with SHA512 ISA extension
- AVX2+BMI2+BMI1: fallback
The added implementation has its own copy of `K512` without duplicated
elements every 16 bytes. Shuffle indices have been reused from `K512`.
Added binary translators for `vsha512msg1`, `vsha512msg2`,
`vsha512rnds2` for older assemblers.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/26147)
We need to temporarily disable this as we have a build break in CI:
https://github.com/openssl/openssl/actions/runs/14192630435
Its occuring because gost-engine depends on libprov, which requires a
minimum version cmake-3.0. The update of github runners to cmake-4.0
causes a bail out as cmake 4.0 no longers supports cmake 3.0 syntax.
Libprov is fixed now, but gost-engine needs to update its libprov
submodule, and then we need to update the gost-engine submodule. Until
thats done (which may take days), we should disable the gost-engine
external tests
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27234)
done this without running mkerr.pl otherwise
this is what mkerr.pl would do:
* remove BIO_err_is_non_fatal from bio_err.c
* remove duplicate BIO_R_PORT_MISMATCH
* reorder/sort 3 things
* update copyright year from 2022 to 2025
see #27183
CLA: trivial
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27191)
We use the same extension-parsing function on server and client
for convenience, but while the server might worry about tracking
what was previously received and not overwriting it, on the client
receiving a request for post-handshake authentication, we always
want to use the values from the current extension (and should
always have a new session object that we are free to mutate).
It is somewhat unclear whether the server also needs the check
for a resumed connection; it appears to have been added back in
2015 in commit 062178678f as part
of a broad pass to handle extensions on resumption, but without
specific documentation of each extension's handling.
Fixes: #10370
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24651)
We encountered another failure in the quic_multistream_test:
https://github.com/openssl/openssl/actions/runs/14127125173/job/39578660601#step:9:1005
It appears we still occasionally get empty frames in our qlog, with the
validate-qlog.py scripts properly bails out on. In the above case, the
offending frame entry looked like this:
{
"name": "transport:packet_received",
"data": {
"header": {
"packet_type": "initial",
"packet_number": 4,
"dcid": "",
"scid": "6217813c336a012a"
},
"datagram_id": 6,
"frames": [
{
"frame_type": "new_token",
"token": {
"raw": {
"data": "44801add5794"
}
},
"length": 8
},
{
"frame_type": "stream",
"stream_id": 15897,
"offset": 625652585,
"payload_length": 11,
"explicit_length": true,
"fin": true,
"length": 8
},
{} <= NOTE EMPTY FRAME HERE
]
},
"time": 0
}
I think we're still missing some frame formatting cases in
script_21_inject_plain(), which can format potentially any of the frames
listed in the forbidden_frame_types array when running the
test_dyn_frame_types test.
I think we need to enumerate all of those frame types in the case
statement we have there. Fortunately we generally don't have to provide
sane values, and most of the cases fall into 4 categories (those that
need a 64 bit data value, and those that require 1, 2 or 3 variable
integers). There are two special cases, NEW_TOKEN, and NEW_CONNECTION,
but those just need a mix of fixed and variable width data.
So lets fully enumerate those and hopefully put this to bed.
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/27200)
- Tolerate RSA PKCS#1 *certificate* signatures when
the peer sigals include RSA PSS with the same digest.
Now that we're more strict about not sending sigalgs that are out of
protocol range, when the client supports TLS 1.3 only, we might refuse
to return an RSA PKCS#1-signed cert.
- Don't send TLS 1.3 sigalgs when requesting client certs from
a TLS 1.2 client.
Fixes: #1144Fixes: #25277
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27166)
mingw-w64 only defines LPCTCH when UNICODE isn't defined
crypto/defaults.c: In function 'get_windows_regdirs':
crypto/defaults.c:72:5: error: unknown type name 'LPCTCH'; did you mean 'LPTCH'?
72 | LPCTCH tempstr = NULL;
| ^~~~~~
| LPTCH
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26566)
String litteral don't need the '##' operator, which causes build
failures:
crypto/defaults.c:kepi:23: error: pasting ""SOFTWARE\\WOW6432Node\\OpenSSL"" and ""-"" does not give a valid preprocessing token
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26566)
There are a few more critical frame injections that
previously created an out-of-diskspace problem
and now only a CI test failure. The pattern
in the qlog files is always similar to this:
{"frame_type":"stop_sending","stream_id":6,"error_code":1152,"length":4},
{"frame_type":"path_challenge","length":9},...{}
Note: The stream_id 6 is a OSSL_QUIC_FRAME_TYPE_CRYPTO.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/27170)
