In reply to @a-n-n-a-l-e-e:matrix.org
hello -- i deleted my github account today due to being angry at some dumpster fire of a PR i got involved with. anyway, some of my other work is now being questioned about me being part of the xz conspiracy https://github.com/NixOS/nixpkgs/pull/301252 i recognize the suspicion but that was just due to the work of cleaning up segfaults and libc++abi / libc++ stuff from LLVM.

In reply to @a-n-n-a-l-e-e:matrix.org
i knew getting involved in the PR was a mistake last week but i did it anyway. (https://github.com/NixOS/nixpkgs/pull/294347)

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 :/ )

The security researchers at exploit.org claimed they've found an RCE in Telegram Desktop's latest version (seems 4.16.1 at least), and updated a demonstration video targeting Windows build. Someone in the comment claimed they could not trigger the PoC in 4.16.4.

Original message:

Link: https://t.me/exploitorg/30

The security researchers at exploit.org claimed they've found an RCE in Telegram Desktop's latest version (seems 4.16.1 at least), and updated a demonstration video targeting Windows build. Someone in the comment claimed they could not trigger the PoC in 4.16.4.

Original message:

SECURITY ALERT ⚠️

Possible RCE was detected in Telegram's media processing in Telegram Desktop application.
This issue expose users to malicious attacks through specially crafted media files, such as images or videos.

For security reasons disable auto-download feature. Please follow these steps:
1. Go to Settings.
2. Tap on "Advanced".
3. Under the "Automatic Media Download" section, disable auto-download for "Photos", "Videos", and "Files" across all chat types (Private chats, groups, and channels).

We are currently investigating this vulnerability.

Link: https://t.me/exploitorg/30

The security researchers at exploit.org claimed they've found an RCE in Telegram Desktop's latest version (seems 4.16.1 at least), and updated a demonstration video targeting Windows build. Someone in the comment claimed they could not trigger the PoC in 4.16.4.

Currently 23.11 and unstable branch has 4.16.1, and master was updated to 4.16.4 yesterday.

Original message:

SECURITY ALERT ⚠️

Possible RCE was detected in Telegram's media processing in Telegram Desktop application.
This issue expose users to malicious attacks through specially crafted media files, such as images or videos.

For security reasons disable auto-download feature. Please follow these steps:
1. Go to Settings.
2. Tap on "Advanced".
3. Under the "Automatic Media Download" section, disable auto-download for "Photos", "Videos", and "Files" across all chat types (Private chats, groups, and channels).

We are currently investigating this vulnerability.

Link: https://t.me/exploitorg/30