Quoting: sudoer

Quoting: pleasereadthemanualMissed this comment the first time. This does not inspire confidence in me about using Arch in the future.

huh? maybe you missed that "The malicious code path does not exist in the arch version of sshd, as it does not link to liblzma" too. Also, how many "home" users use a ssh server...

QuoteSecurity
Be aware that in some circumstances (e.g., where the program specifies an ELF interpreter other than ld-linux.so), some versions of ldd may attempt to obtain the dependency information by attempting
to directly execute the program, which may lead to the execution of whatever code is defined in the program's ELF interpreter, and perhaps to execution of the program itself. (Before glibc 2.27, the
upstream ldd implementation did this for example, although most distributions provided a modified version that did not.)

Thus, you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code. A safer alternative when dealing with untrusted executables is:

$ objdump -p /path/to/program | grep NEEDED

Note, however, that this alternative shows only the direct dependencies of the executable, while ldd shows the entire dependency tree of the executable.

Quoting: pleasereadthemanualIt gets a lot worse. This bad actor has made contributions all over core Linux projects like systemd: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5005888#gistcomment-5005888

Quoting: williamjcm

QuoteSo you'll want to ensure any XZ packages are not at version 5.6.0 or 5.6.1, and check the news directly from your chosen distribution for updates on it.

Arch has repackaged 5.6.1, using a repo clone instead of the compromised tarballs: https://security.archlinux.org/ASA-202403-1
https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad

Quoting: pleasereadthemanual

Quoting: whizseOh, this might be bad. Seems like an inside job by the new'ish maintainer:

https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

If so, someone needs to go through xz-utils with a fine toothed comb.

So it would seem that this new maintainer has been trying to gain control of XZ since 2021, and has had control of it since 2023. That's quite concerning and surprising. It seems unusual for bad actors to try to gain control of the supply chain long-term. Older XZ releases might have other unreported vulnerabilities even on stable distributions...

This maintainer has at least 750 commits to his name: https://hachyderm.io/@joeyh/112180715824680521

But to quote Glyph:

QuoteI really hope that this causes an industry-wide reckoning with the common practice of letting your entire goddamn product rest on the shoulders of one overworked person having a slow mental health crisis without financially or operationally supporting them whatsoever. I want everyone who has an open source dependency to read this message https://www.mail-archive.com/[email protected]/msg00567.html

Quoting: whizseOh, this might be bad. Seems like an inside job by the new'ish maintainer:

https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

If so, someone needs to go through xz-utils with a fine toothed comb.

QuoteI really hope that this causes an industry-wide reckoning with the common practice of letting your entire goddamn product rest on the shoulders of one overworked person having a slow mental health crisis without financially or operationally supporting them whatsoever. I want everyone who has an open source dependency to read this message https://www.mail-archive.com/[email protected]/msg00567.html

Quoting: pilkI'm glad they're finally doing this, but this should've been implemented, at the very least, after the first time this happened.

Quoting: Eike

Quoting: pleasereadthemanualYou see, it's actually really simple.

(...writes a manual...)

Quoting: Eike

Quoting: pleasereadthemanualI get the distinct feeling I'm missing something...

(Serious) question: Mesa?

Quoting: Marlockthey could delay SDL3... but that only helps if Wayland devs clearly signal they'll solve their end of the issue soon with high priority... which seems a bit unlikely, though Valve does have plenty of people working for them on both things, iirc

Quoting: hell0

Quoting: pleasereadthemanual

QuoteIf we do this, we are basically accepting these issues are unfixable for the next ten years (SDL4).

[...]

Shipping a broken default is the wrong thing to do. Unfortunately, that protocol is unlikely to be finished before SDL3's release (3+ months away).

Two bad options. There's suggestions of flipping the default later on in the lifecycle of SDL3 once this protocol is implemented, and that seems like what's going to happen. I'm not sure what the downsides of this are.

I'm not interested enough to go and read the whole debate. But is there really a 10 year life cycle for SDL? Or something preventing them from releasing SLD4 a year from now?