botan2 and botan3 had bug fix releases roughly a month ago. I made a combined PR some weeks ago, but was not able to debug the failing build of monotone with botan2 on MacOS myself. So I split this PR into a another one for botan2.

• botan3: https://github.com/NixOS/nixpkgs/pull/298669
• botan2: https://github.com/NixOS/nixpkgs/pull/302530

Is someone willing to step in for debugging the failing botan2 build on MacOS or can provide me some debugging hints for debugging from a Linux-based system with ofborg in the CI?

botan2 and botan3 had bug fix releases roughly a month ago. I made a combined PR some weeks ago, but was not able to debug the failing build of monotone with botan2 on MacOS myself. So I split this PR into another one for botan2.

• botan3: https://github.com/NixOS/nixpkgs/pull/298669
• botan2: https://github.com/NixOS/nixpkgs/pull/302530

Is someone willing to step in for debugging the failing botan2 build on MacOS or can provide me some debugging hints for debugging from a Linux-based system with ofborg in the CI?

OpenSSL Security Advisory [8th April 2024]
==========================================

Unbounded memory growth with session handling in TLSv1.3 (CVE-2024-2511)
========================================================================

Severity: Low

Issue summary: Some non-default TLS server configurations can cause unbounded
memory growth when processing TLSv1.3 sessions

Impact summary: An attacker may exploit certain server configurations to trigger
unbounded memory growth that would lead to a Denial of Service

This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is
being used (but not if early_data support is also configured and the default
anti-replay protection is in use). In this case, under certain conditions, the
session cache can get into an incorrect state and it will fail to flush properly
as it fills. The session cache will continue to grow in an unbounded manner. A
malicious client could deliberately create the scenario for this failure to
force a Denial of Service. It may also happen by accident in normal operation.

This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS
clients.

The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL
1.0.2 is also not affected by this issue.

OpenSSL 3.2, 3.1, 3.0, 1.1.1 are vulnerable to this issue.

OpenSSL 3.2 users should upgrade to OpenSSL 3.2.2 once it is released.

OpenSSL 3.1 users should upgrade to OpenSSL 3.1.6 once it is released.

OpenSSL 3.0 users should upgrade to OpenSSL 3.0.14 once it is released.

OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1y once it is released
(premium support customers only).

Due to the low severity of this issue we are not issuing new releases of
OpenSSL at this time. The fix will be included in the next releases when they
become available. The fix is also available in commit e9d7083e (for 3.2),
commit 7e4d731b (for 3.1) and commit b52867a9 (for 3.0) in the OpenSSL git
repository. It is available to premium support customers in commit
5f8d2577 (for 1.1.1).

This issue was reported on 27th February 2024 by Manish Patidar (Hewlett Packard
Enterprise). The fix was developed by Matt Caswell.

Envoy 1.27.4 (CVE-2024-30255) https://github.com/envoyproxy/envoy/releases/tag/v1.27.4

cc lukegb (he/him) (build is already kind of broken and only work thanks to caching of the deps :/ )