Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
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/26897)
Signed-off-by: Ondrej Moris <omoris@redhat.com>
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26899)
We use the coreutils format since 3.4.0.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26907)
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/26925)
When displaying distinguished names the control characters
are escaped by default.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26932)
The quic_multistream_test occasionally fails script_84, specifically
failing on:
OP_CHECK2(check_write_buf_stat, 0, 0)
which fails due to the send stream buffer not reading zero after data is
sent on the stream
However, the send stream is culled of pending data, not after the stream
is sent, but rather only after the peer sends an ack confirming that the
data has been received. There is no guarantee that ACK will be sent
immediately, so occasionally timing discrepancies result in the test not
getting that ack by the time we check the send stream buffer.
We couldmodify the script to wait longer, or repeatedly tick the quic
stack to wait for that ack to be collected, but since its perfectly
valid for that data to live in the ring buffer for a period, and that
any true erroneous keeping of that data beyond its ack point would
manifest as any number of other duplicate transmissions, it seems more
sane to just remove the check.
Fixesopenssl/project#1117
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26939)
We move ssl_err.c out of libssl and into libcrypto. This file is entirely
self contained and is used to load error strings into the libcrypto error
tables. By moving this file into libcrypto, libssl can be unloaded safely
without having dangling references to this error information.
Fixes#26672
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26931)
- The decoder should consider fewer options based on
more precise tracking of the desired input type
(DER, PVK, MSBLOB), algorithm (RSA, EC, ...),
input structure (SPKI, P8, ...).
How much this affects actual use-cases is harder to estimate, we'll just
have to run before/after perf tests.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26927)
EVP_DecodeUpdate() should not produce zeros for input padding `=` signs to avoid writing to non-allocated memory regions.
To achieve this:
- Add `eof` parameter to `evp_decodeblock_int` function in `openssl/crypto/evp`. The parameter should either contain the number of the input padding characters to ignore or `-1` if the function has to count them.
- Use precalculated `eof` in `EVP_DecodeUpdate` to fix its behaviour.
- Use `eof = -1` in `EVP_DecodeFinal` to count it in `evp_decodeblock_int`.
- Do not ignore padding in `EVP_DecodeBlock` (`eof = 0`) because it should write padding zeros according to the documentation.
- Add the HISTORY section to EVP_EncodeInit documentation to describe the fix.
Other changes:
- Update AUTHORS.md
- Update the copyright date in the documentation.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26678)
When both seed and key are provided compare the full ML-KEM private key
with the seed keygen output, not just the public key.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26905)
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/26908)
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26916)
twice.
Fixes#26862
This only happens when using the FIPS provider, since it needs to export
the key.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26891)
Don't expect success with dated FIPS modules.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26904)
The decoders in some cases failed to capture or propagate
information about what is being decoded, causing more work
happen to try unrelated decoders as a fallback.
We now try harder to keep track of the expected object (private key or
public key, if known), and the algorithm determined from the OID of a
PKCS8 object or SPKI. This leads in many cases to fewer decoder
invocations. With so many more algorithms now, trying every decoder
is increasingly best avoided.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26892)
Added a python script to convert the json files into evp_test data.
Added a EVP_TEST_METHOD "KeyFromData" that can test failures when
loading raw keys. (The existing "PrivateKeyRaw" and "PublicKeyRaw"
were not fit for this purpose).
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26885)
Also move the deprecated curves to the end of the list, and order the
soon most preferred groups first.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26873)
Fixes#26876
The issue here is that the pbkdf2 'lower_bounds_checks' currently errors by default
in FIPS mode if iterations < 1000.
i.e. the "pkcs5" flag = 0 triggers an error..
Turning the flag on means the FIPS indicator is triggered (which is probably correct behaviour)
Not sure testing the fips state here is a good idea (i.e. taking a TSAN hit).
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26887)
The slh_dsa fuzzer predicts failure in EVP_message_sign_init in the
event we pass a context_string param of more than 255 bytes. That makes
for an accurate prediction, but only if we actually create the param.
augment the setting of exepct_rc_init to be determined not only by our
allocation of a > 255 byte message, but also on selector bit 1, which
determines if we create the parameter at all.
Fixes https://oss-fuzz.com/testcase-detail/4807793999937536
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/26884)
Add this to our regression test suite for tlsfuzzer, since it recently
caught an error
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26781)
From RFC 8446:
Note: TLS defines two generic alerts (see Section 6) to use upon
failure to parse a message. Peers which receive a message which
cannot be parsed according to the syntax (e.g., have a length
extending beyond the message boundary or contain an out-of-range
length) MUST terminate the connection with a "decode_error" alert.
Peers which receive a message which is syntactically correct but
semantically invalid (e.g., a DHE share of p - 1, or an invalid enum)
MUST terminate the connection with an "illegal_parameter" alert.
A zero length cipher suite list I think is considered out of range, and
so we should return "decode_error" rather than "illegal_parameter"
Fixes#25309
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26781)
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/25930)
FIPS 3.0.9 provider does not honor runtime seed configuration, thus if
one desires to use JITTER entropy source with FIPS 3.0.9 provider
something like this needs to be applied to the core (libcrypto) build.
Not sure if this is at all suitable for upstream.
With fips-jitter (3.5+) config, also ensure that core<->provider
callback for entropy uses jitter entropy source, rather than os seed
(getrandom syscall).
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/25930)
This issue was discoevered while I was testing SSL_new_from_listener()
using a newly created unit test. It has turned out the QUIC stack
at few places contain pattern as follows:
foo(QUIC_WHATEVER *q, BIO_ADDR *a)
{
q->a = *a;
}
The problem is that derefencning a that way is risky. If the address `a`
comes from BIO_lookup_ex() it may actually be shorter than sizeof(BIO_ADDR).
Using BIO_ADDR_copy() is the right thing to do here.
Fixes#26241
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26252)
If sk_POLICYQUALINFO_push() fails, qual is not freed.
Fix it by adding POLICYQUALINFO_free() to the error path.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26499)
get1_cert_status() returns an object that must be freed,
but the error path does not do that.
Fix it by adding a call to X509_free() in the error path.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26513)
It is no longer static.
Also add it to libssl only with quic enabled.
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26882)
There are several cases where new BIGNUM instances are created, not
using the context, but not freed when an error occurs.
Fix this by adding the necessary calls to BN_free().
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26515)
Do not raise ERR_LIB_CONF codes from libssl.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26801)
The test_bio_ssl test in quicapitest is failing on windows. Something
about the timing there is causing wide variance in how long it takes to
establish a handshake (between 130-6500 iterations).
Convert it to use fake time to make it run consistently.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26801)
As the COOKIE_ONLY cannot run on no-ecx build.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26801)
Of course TLS-1.3 won't be usable with such configuration.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26801)
