⨯ Every article tag can be clicked to get a list of all articles in that category. Every article tag also has an RSS feed! You can customize an RSS feed too!
Latest Comments by pleasereadthemanual
KDE's Xaver Hugl on why Wayland explicit sync is such a big deal
9 April 2024 at 9:11 am UTC
Quoting: TheRiddickBe a great day once NVIDIA gets [..] properly balanced HDR (is desaturated and wrong exposure atm).
Is HDR even available at all? As far as I know, KDE only offers a partially-implemented version of HDR on their Wayland session.
Wine 9.6 released with more Direct2D effects work, support for RSA OAEP padding in BCrypt
6 April 2024 at 12:07 am UTC Likes: 3
Solidworks does work in Wine? That's surprising.

I've never used it, but isn't that a popular industry-standard CAD program?
Battlefield V now broken on Steam Deck / Linux with EA anticheat live
5 April 2024 at 6:58 am UTC Likes: 1
If Ubisoft won't enable anti-cheat support for Proton for Siege even when it's seemingly done for them, I don't have much hope for these EA games using an unsupported anti-cheat.

I don't think the anti-cheat problem will ever be solved for Linux.
XZ tools and libraries compromised with a critical issue
31 March 2024 at 2:37 am UTC Likes: 4
Quoting: pleasereadthemanualDowngrading to an earlier version of xz sounds like the most reasonable thing to do based on what Nix and Gentoo are doing.
Thinking about it some more, this could also be a bad idea if you downgrade to previous Arch packages. They were built from tarballs signed by the maintainer, which could be hiding more surprises. You would want to make doubly sure that the release you are using was based on tarballs signed by Lasse and not Jia Tan.

At least with the 5.6.1-2 release, you can be assured that Arch is building the package directly from git, with no binary surprises in the tarballs.
XZ tools and libraries compromised with a critical issue
31 March 2024 at 1:14 am UTC Likes: 1
Quoting: sudoerso you are saying they should use the compromised binary tarballs instead. You said it twice already.
I'm not. In the interest of caution, I downgraded to an earlier version of xz. I would have felt more reassured had Arch done the same, as every other affected distribution has done. I overstated that in my initial comment, I admit. Hopefully it turns out there was no need for Arch to go further back.

What worries me is that other parts of xz may have been sabotaged. Lasse recently reverted a commit that disabled the Landdlock sandbox e.g., but this is benign: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00

Quoting: sudoerI'm not sure you understand the situation and are basically copy-pasting stuff you find elsewhere here pretending to know a thing.

https://bbs.archlinux.org/viewtopic.php?pid=2160841#p2160841
I'm doing my best to understand the situation. I'm not a security researcher, packager, or developer; just a user. Downgrading to an earlier version of xz sounds like the most reasonable thing to do based on what Nix and Gentoo are doing.
XZ tools and libraries compromised with a critical issue
30 March 2024 at 9:48 am UTC Likes: 2
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...
My issue is that Arch, unlike openSUSE, Gentoo, Nix, Fedora Rawhide, Fedora 40/41, Kali Linux, and Homebrew, are continuing to use the 5.6.1 release, just pulling directly from Github and not the binary tarballs which were compromised. All of these other distributions have downgraded to 5.4.6. Gentoo has gone so far as to downgrade to 5.4.2, which is the last release signed by the previous maintainer.

That's because none of these distributions have fully analyzed the source for xz, and out of concern that there is more malware hiding in the weeds, they've gone further back.

Also, the Arch Linux news post recommended using ldd on the xz executable which was known to be malicious in at least one way. You should never do this. Read the man page for ldd for why:

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.
And for the record, I use an SSH server.

I don't understand why Arch is choosing to trust that very recent versions of xz are not compromised without much further investigation.

That being said, this should probably be disregarded:

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
This developer is significantly more trustworthy. So at this stage, it's hopefully only xz that's compromised.

Also worth mentioning that this impacted Homebrew for macOS users.
XZ tools and libraries compromised with a critical issue
30 March 2024 at 5:49 am UTC Likes: 3
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
Missed this comment the first time. This does not inspire confidence in me about using Arch in the future.
XZ tools and libraries compromised with a critical issue
30 March 2024 at 1:27 am UTC Likes: 4
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
Edit: This comment originally linked to another comment about another related developer. But there's good reason to believe that this supply chain attack is limited to xz for now.

A malicious patch series almost got into the kernel, too.

Github has removed the xz repository entirely.
XZ tools and libraries compromised with a critical issue
30 March 2024 at 12:39 am UTC Likes: 9
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
Oh Snap! Canonical now doing manual reviews for new packages due to scam apps
29 March 2024 at 4:52 am UTC Likes: 6
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.
In 2018?
★ Support Us
Popular this week
Search or view by category
Contact
Latest Comments
Latest Forum Posts
Misc