<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openssl/fuzz, branch feature/engineremoval</title>
<subtitle>TLS/SSL and crypto library.</subtitle>
<id>http://git.bktus.com/gpgfrontend/openssl/atom?h=feature%2Fengineremoval</id>
<link rel='self' href='http://git.bktus.com/gpgfrontend/openssl/atom?h=feature%2Fengineremoval'/>
<link rel='alternate' type='text/html' href='http://git.bktus.com/gpgfrontend/openssl/'/>
<updated>2025-10-04T08:28:50Z</updated>
<entry>
<title>Reduce Max number of commands handled per fuzzer pass in quic-lcidm.</title>
<updated>2025-10-04T08:28:50Z</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@openssl.org</email>
</author>
<published>2025-10-01T21:34:38Z</published>
<link rel='alternate' type='text/html' href='http://git.bktus.com/gpgfrontend/openssl/commit/?id=01c7958f2359e951a95350affb6b178fb50fed03'/>
<id>urn:sha1:01c7958f2359e951a95350affb6b178fb50fed03</id>
<content type='text'>
We've gotten a few recent reports of a hang in the quic-lcidm fuzzer:

https://issues.oss-fuzz.com/issues/448510502

It looks pretty straightforward (I think).  The fuzzer input buffer is
used in this particular case to randomly issue commands to the lcidm
hash table (add/delete/query/flush/etc).

The loop for the command processing (based on the input buffer), is
limited to 10k commands.  However the fuzzer will on occasion provide
very large buffers (500k) which easily saturate that limit.  If the
input buffer happens to do something like get biased toward mostly
additions, we wind up with a huge hashtable that has to constantly grow
and rehash, which we've seen leads to timeouts in the past.

Most direct fix I think here, given that this is something of an
artificial failure in the fuzzer, is to simply clamp the command limit
more.

Fixes openssl/project#1664

Reviewed-by: Kurt Roeckx &lt;kurt@roeckx.be&gt;
Reviewed-by: Matt Caswell &lt;matt@openssl.org&gt;
Reviewed-by: Tomas Mraz &lt;tomas@openssl.org&gt;
(Merged from https://github.com/openssl/openssl/pull/28724)
</content>
</entry>
<entry>
<title>hashtable: add option to disable RCU locks</title>
<updated>2025-10-02T12:05:02Z</updated>
<author>
<name>Nikola Pajkovsky</name>
<email>nikolap@openssl.org</email>
</author>
<published>2025-09-25T16:32:17Z</published>
<link rel='alternate' type='text/html' href='http://git.bktus.com/gpgfrontend/openssl/commit/?id=512f176185ebcd98810e181601fcaf7f340439e9'/>
<id>urn:sha1:512f176185ebcd98810e181601fcaf7f340439e9</id>
<content type='text'>
a new config option _no_rcu_ is added into HT_CONFIG. When _no_rcu_ is
set then hashtable can be guarded with any other locking primitives,
and behives as ordinary hashtable. Also, all the impact of the
atomics used internally to the hash table was mitigated.

RCU performance

   # INFO:  @ test/lhash_test.c:747
   # multithread stress runs 40000 ops in 40.779656 seconds

No RCU, guarded with RWLOCK

   # INFO:  @ test/lhash_test.c:747
   # multithread stress runs 40000 ops in 36.976926 seconds

Signed-off-by: Nikola Pajkovsky &lt;nikolap@openssl.org&gt;

Reviewed-by: Saša Nedvědický &lt;sashan@openssl.org&gt;
Reviewed-by: Tomas Mraz &lt;tomas@openssl.org&gt;
Reviewed-by: Neil Horman &lt;nhorman@openssl.org&gt;
(Merged from https://github.com/openssl/openssl/pull/28677)
</content>
</entry>
<entry>
<title>Add util/codespell-check.sh and run it</title>
<updated>2025-09-26T11:58:44Z</updated>
<author>
<name>Bob Beck</name>
<email>beck@openssl.org</email>
</author>
<published>2025-09-22T19:51:32Z</published>
<link rel='alternate' type='text/html' href='http://git.bktus.com/gpgfrontend/openssl/commit/?id=e70d3b1886a0fadbbe47401a9d46114f05bec80d'/>
<id>urn:sha1:e70d3b1886a0fadbbe47401a9d46114f05bec80d</id>
<content type='text'>
Reviewed-by: Neil Horman &lt;nhorman@openssl.org&gt;
Reviewed-by: Tomas Mraz &lt;tomas@openssl.org&gt;
Reviewed-by: Richard Levitte &lt;levitte@openssl.org&gt;
(Merged from https://github.com/openssl/openssl/pull/28639)
</content>
</entry>
<entry>
<title>Copyright year updates</title>
<updated>2025-09-02T13:05:45Z</updated>
<author>
<name>openssl-machine</name>
<email>openssl-machine@openssl.org</email>
</author>
<published>2025-09-02T13:05:45Z</published>
<link rel='alternate' type='text/html' href='http://git.bktus.com/gpgfrontend/openssl/commit/?id=e66332418f84144478df43df91cf4cedf412fc85'/>
<id>urn:sha1:e66332418f84144478df43df91cf4cedf412fc85</id>
<content type='text'>
Reviewed-by: Neil Horman &lt;nhorman@openssl.org&gt;
Reviewed-by: Saša Nedvědický &lt;sashan@openssl.org&gt;
Release: yes
</content>
</entry>
<entry>
<title>Fix failure checking on rcu_read_lock</title>
<updated>2025-08-09T13:22:13Z</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@openssl.org</email>
</author>
<published>2025-08-07T13:50:58Z</published>
<link rel='alternate' type='text/html' href='http://git.bktus.com/gpgfrontend/openssl/commit/?id=036a46d2a4b00a004d05dc6a6d19be7184f8ecf1'/>
<id>urn:sha1:036a46d2a4b00a004d05dc6a6d19be7184f8ecf1</id>
<content type='text'>
during memfail testing:
https://github.com/openssl/openssl/actions/runs/16794088536/job/47561223902

We get lots of test failures in ossl_rcu_read_lock.  This occurs
because we have a few cases in the read lock path that attempt mallocs,
which, if they fail, trigger an assert or a silent failure, which isn't
really appropriate.  We should instead fail gracefully, by informing the
caller that the lock failed, like we do for CRYPTO_THREAD_read_lock.

Fortunately, these are all internal apis, so we can convert
ossl_rcu_read_lock to return an int indicating success/failure, and fail
gracefully during the test, rather than hitting an assert abort.

Fixes openssl/project#1315

Reviewed-by: Paul Yang &lt;paulyang.inf@gmail.com&gt;
Reviewed-by: Dmitry Belyavskiy &lt;beldmit@gmail.com&gt;
Reviewed-by: Paul Dale &lt;ppzgs1@gmail.com&gt;
(Merged from https://github.com/openssl/openssl/pull/28195)
</content>
</entry>
<entry>
<title>apps, fuzz, providers: use array memory (re)allocation routines</title>
<updated>2025-08-08T16:22:10Z</updated>
<author>
<name>Eugene Syromiatnikov</name>
<email>esyr@openssl.org</email>
</author>
<published>2025-07-23T13:49:18Z</published>
<link rel='alternate' type='text/html' href='http://git.bktus.com/gpgfrontend/openssl/commit/?id=f3a4d05c5889b571d8b99c645fa41533b27ec44b'/>
<id>urn:sha1:f3a4d05c5889b571d8b99c645fa41533b27ec44b</id>
<content type='text'>
Co-Authored-by: Alexandr Nedvedicky &lt;sashan@openssl.org&gt;
Signed-off-by: Eugene Syromiatnikov &lt;esyr@openssl.org&gt;

Reviewed-by: Saša Nedvědický &lt;sashan@openssl.org&gt;
Reviewed-by: Matt Caswell &lt;matt@openssl.org&gt;
Reviewed-by: Paul Dale &lt;ppzgs1@gmail.com&gt;
Reviewed-by: Neil Horman &lt;nhorman@openssl.org&gt;
(Merged from https://github.com/openssl/openssl/pull/28059)
</content>
</entry>
<entry>
<title>fuzz/dtlsserver.c: Remove incorrect ifdef guard</title>
<updated>2025-07-30T16:31:47Z</updated>
<author>
<name>Michael Baentsch</name>
<email>57787676+baentsch@users.noreply.github.com</email>
</author>
<published>2025-07-28T04:52:49Z</published>
<link rel='alternate' type='text/html' href='http://git.bktus.com/gpgfrontend/openssl/commit/?id=fd7fc90346306f49773866eddff90717e22b9181'/>
<id>urn:sha1:fd7fc90346306f49773866eddff90717e22b9181</id>
<content type='text'>
Reviewed-by: Kurt Roeckx &lt;kurt@roeckx.be&gt;
Reviewed-by: Matt Caswell &lt;matt@openssl.org&gt;
Reviewed-by: Tomas Mraz &lt;tomas@openssl.org&gt;
(Merged from https://github.com/openssl/openssl/pull/28102)
</content>
</entry>
<entry>
<title>Implement KEMRecipientInfo (RFC9629) in CMS</title>
<updated>2025-07-30T09:39:04Z</updated>
<author>
<name>Daniel Van Geest</name>
<email>daniel.vangeest@cryptonext-security.com</email>
</author>
<published>2025-04-03T10:19:43Z</published>
<link rel='alternate' type='text/html' href='http://git.bktus.com/gpgfrontend/openssl/commit/?id=d0899abb1b7654922b2272070d8fb593d8b13cff'/>
<id>urn:sha1:d0899abb1b7654922b2272070d8fb593d8b13cff</id>
<content type='text'>
Also add support for ML-KEM in CMS (draft-ietf-lamps-cms-kyber).

Add the -recip_kdf and -recip_ukm parameters to `openssl cms -encrypt`
to allow the user to specify the KDF algorithm and optional user
keying material for each recipient.

A provider may indicate which RecipientInfo type is supported
for a key, otherwise CMS will try to figure it out itself. A
provider may also indicate which KDF to use in KEMRecipientInfo
if the user hasn't specified one.

Reviewed-by: Dmitry Belyavskiy &lt;beldmit@gmail.com&gt;
Reviewed-by: Tomas Mraz &lt;tomas@openssl.org&gt;
(Merged from https://github.com/openssl/openssl/pull/27681)
</content>
</entry>
<entry>
<title>Add HKDF algorithms with fixed digests.</title>
<updated>2025-07-10T01:13:21Z</updated>
<author>
<name>Daniel Van Geest</name>
<email>daniel.vangeest@cryptonext-security.com</email>
</author>
<published>2025-04-03T09:45:20Z</published>
<link rel='alternate' type='text/html' href='http://git.bktus.com/gpgfrontend/openssl/commit/?id=d1a8d5a8330a8c9d939e18a22f7382af090cf108'/>
<id>urn:sha1:d1a8d5a8330a8c9d939e18a22f7382af090cf108</id>
<content type='text'>
Add HKDF-SHA256, HKDF-SHA384 and HKDF-SHA512 which are versions
of HKDF that have the digest pre-set. The digest cannot be changed
for contexts of these types.

RFC 8619 defines algorithm identifiers for these combinations.
These algorithm identifiers will be used in future features, e.g.
KEMRecipientInfo.

Reviewed-by: Shane Lontis &lt;shane.lontis@oracle.com&gt;
Reviewed-by: Tomas Mraz &lt;tomas@openssl.org&gt;
Reviewed-by: Paul Dale &lt;ppzgs1@gmail.com&gt;
(Merged from https://github.com/openssl/openssl/pull/27247)
</content>
</entry>
<entry>
<title>fuzz: Silence warnings on Win64 builds</title>
<updated>2025-07-02T15:26:26Z</updated>
<author>
<name>Tomas Mraz</name>
<email>tomas@openssl.org</email>
</author>
<published>2025-06-18T08:50:27Z</published>
<link rel='alternate' type='text/html' href='http://git.bktus.com/gpgfrontend/openssl/commit/?id=c2482c68e5ce21bc36287103e1b527ab329a8a3d'/>
<id>urn:sha1:c2482c68e5ce21bc36287103e1b527ab329a8a3d</id>
<content type='text'>
Reviewed-by: Saša Nedvědický &lt;sashan@openssl.org&gt;
Reviewed-by: Neil Horman &lt;nhorman@openssl.org&gt;
(Merged from https://github.com/openssl/openssl/pull/27806)
</content>
</entry>
</feed>
