OpenSUSE Tumbleweed has it. The Fedora 40 beta has it. Its just a result of being bleeding edge. Arch doesn't have exclusive rights to that.
this post was submitted on 30 Mar 2024
286 points (84.7% liked)
linuxmemes
21060 readers
263 users here now
Hint: :q!
Sister communities:
- LemmyMemes: Memes
- LemmyShitpost: Anything and everything goes.
- RISA: Star Trek memes and shitposts
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack members of the community for any reason.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
- These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
I thought Arch was the only rolling distro that doesn't have the backdoor. Its sshd is not linked with liblzma, and even if it were, they compile xz directly from git so they wouldn't have gotten the backdoor anyway.
TBF they only switched to building from git after they were notified of the backdoor yesterday. Prior to that, the source tarball was used.
liblzma is the problem. sshd is just the first thing they found that it is attacking. liblzma is used by firefox and many other critical packages.
Arch does not directly link openssh to liblzma, and thus this attack vector is not possible. You can confirm this by issuing the following command:
ldd "$(command -v sshd)"
Yes, this sshd attack vector isn't possible. However, they haven't decomposed the exploit and we don't know the extent of the attack. The reporter of the issue just scratched the surface. If you are using Arch, you should run pacman right now to downgrade.
They actually have an upgrade fix for it, at least for the known parts of it. Doing a standard system upgrade will replace the xz package with one with the known backdoor removed.
I switched it with 5.4, just in case.
Bold of you to assume I hare upgraded in the first place.
If you are using Arch, you should run pacman right now to downgrade.
No, just update. It's already fixed. Thats the point of rolling release.
Interestingly, looking at Gentoo's package, they have both the github and tukaani.org URLs listed:
https://github.com/gentoo/gentoo/blob/master/app-arch/xz-utils/xz-utils-5.6.1.ebuild#L28
From what I understand, those wouldn't be the same tarball, and might have thrown an error.
most stable
How the hell is arch more stable than Debian?
i think it’s a matter of perspective. if i’m deploying some containers or servers on a system that has well defined dependencies then i think Debian wins in a stability argument.
for me, i’m installing a bunch of experimental or bleeding edge stuff that is hard to manage in even a non LTS Debian system. i don’t need my CUDA drivers to be battle tested, and i don’t want to add a bunch of sketchy links to APT because i want to install a nightly version of neovim with my package manager. Arch makes that stuff simple, reliable, and stable, at least in comparison.
In my experience they're the same from a reliability standpoint. Stuff on Arch will break for no reason after an update. Stuff on Debian will break for no reason after an update. It's just as difficult to solve reliability problems on both.
Because Debian isn't a rolling release you will often run into issues where a bug got fixed in a future version of whatever program it is but not the one that's available in the repository. Try using yt-dlp on any stable Debian installation and it won't work for example.
Arch isn't without its issues. Half of the good stuff is on the AUR, and fuck the AUR. Stuff only installs without issues half the time. Good luck installing stuff that needs like 13+ other AUR packages as dependencies because non of that shit can be installed automatically. On other distros,all that stuff can be installed automatically and easily with a single command.
I use Arch btw.
You can get yay for an AUR package manager, but it's generally not recommended because it means blindly trusting the build scripts for community packages that have no real oversight. You're typically advised to check the build script for every AUR package you install.
Difference is, on Debian you can leave machine without updates for few months, while on arch you will have troubles if you don't update for a week, also if you install Linux for your relative, it's better to do debian based distro because of this update cycle since normies don't update their machines every other day, source: I'm daily driving Linux for 9 years on all my machines and some of them lay around untouched for months, also installed mint on relatives PCs, edit: P.S don't know why you get downvoted so much, you generally right but nuances is wrong, anyway, i upvoted you bro, and about yt-dlp on stable, you should install it from python pip repository to have newest version, I'm using yt-dlp on lmde6 and have newest version and it works great
I heard this so many times that I really believed arch was so brittle that my system would become unbootable if I went on vacation. Turns out updating it after 6 months went perfectly fine.
I updated arch after two months and it broke completely, i guess it's because i had unfathomable amount of packages and dependencies, so it varies from person to person, if you keep your system light then it may work like it worked for you, if you install giant amount of packages and dependencies then it would work like it worked for me
Arch has already updated XZ by relying on the source code repository itself instead of the tarballs that did have the manipulations in them.
It's not ideal since we still rely on a potentially *otherwise* compromised piece of code still but it's a quick and effective workaround without massive technical trouble for the issue at hand.
instead of the tarballs that did have the manipulations in them
My only exposure to Linux is SteamOS so I might be misunderstanding something, but if not:
How in the world did it get infected in the first place? Do we know?
From what I read it was one of the contributors. Looks like they have been contributing for some time too before trying to scooch in this back door. Long con.
Basically, one of the contributors that had been contributing for quite some time (and was therefore partly trusted), commited a somewhat hidden backdoor. I doubt it had any effect (as it was discovered now before being pushed to any stable distro and the exploit itself didnt work on Arch) bjt we'll have to wait for the effect to be analyzed.
There are no known reports of those versions being incorporated into any production releases for major Linux distributions, but both Red Hat and Debian reported that recently published beta releases used at least one of the backdoored versions [...] A stable release of Arch Linux is also affected. That distribution, however, isn't used in production systems.
Ouch
Also,
Arch is the most stable
Are you high?
I think the confusion comes from the meaning of stable. In software there are two relevant meanings:
-
Unchanging, or changing the least possible amount.
-
Not crashing / requiring intervention to keep running.
Debian, for example, focuses on #1, with the assumption that #2 will follow. And it generally does, until you have to update and the changes are truly massive and the upgrade is brittle, or you have to run software with newer requirements and your hacks to get it working are brittle.
Arch, for example, instead focuses on the second definition, by attempting to ensure that every change, while frequent, is small, with a handful of notable exceptions.
Honestly, both strategies work well. I've had debian systems running for 15 years and Arch systems running for 12+ years (and that limitation is really only due to the system I run Arch on, rather than their update strategy.
It really depends on the user's needs and maintenance frequency.
A stable release of Arch Linux is
not a thing.
Ars uses AI now?
Arch is not vulnerable to this attack vector. Fedora Rawhide, OpenSUSE Tumbleweed and Debian Testing are.
It has the freshest packages, ahead of all distros
Let me introduce you to Nixpkgs. Its packages are "fresher" than Arch's by a large margin. Even on stable channels.
And the xz package?
Incorrect: the backdoored version was originally discovered by a Debian sid user on their system, and it presumably worked. On arch it's questionable since they don't link sshd with liblzma (although some say some kind of a cross-contamination may be possible via a patch used to support some systemd thingy, and systemd uses liblzma). Also, probably the rolling opensuse, and mb Ubuntu. Also nixos-unstalbe, but it doesn't pass the argv[0] requirements and also doesn't link liblzma. Also, fedora.
what even is xz?
Very common compression utility for LZMA (.xz file)
Similar to .gzip, .zip, etc.
People doesn't even know what ~~a rootkit~~ XZ is, why should they care? -Sony CEO probably
void doesnt have it :3