Who could have seen it coming?
18h 46m ago by sh.itjust.works/u/ar99644 in linuxmemes from sh.itjust.works
Real talk for a moment, there isn’t a system alive that currently solves the supply chain attack issue. there’s a trade-off between usability, and security. You can be a secure as you want to be, all it takes is a small accident by one developer in a package that you’re using, even if they’re using gpg signing to accidentally upload A package that’s been tampered. It stinks, but that’s the reality. What I think should be applauded is the thoroughness that the arch developers are going through the repo right now trying to find these packages. I don’t know the specifics, but if they’re like other open source developers, they’re unpaid people doing this out of their love for the software and community. and more than likely, this is a headache on top of headaches that they already have that they’re doing for the love of the community.
Idk how the AUR works but I like that nix fetch the source from the repo and also check its hash from a maintainer provided one. Prevents repo hijacking.
Although it's still pretty much vulnerable if the attacker controls both the nix file and the repo
Every *-git package also fetch it from the repo. The apt analogy is someone haven't been maintaining the nixpkg and then it gets adopted by someone else. Now that someone else change the build script to be malware. So it is no fault of the upstream
Meanwhile, Windows users: btw, first time? 💀🪢
Wait AUR works in windows?
lol no, but malware does
It is ok, Micro$oft is asking me to call so they can fix it for me.
I legitimately have not had virus issues with Windows in over a decade. Using uBlock Origin for ad blocking and the built in Microsoft antivirus. Every few months for the first few years I'd put it through the wringer of a bunch of USB-bootable antivirus scanners. They kept finding nothing, so I slowed and eventually stopped bothering.
Common sense and an ad blocker do wonders.
To be fair, me neither, but every time somebody has an infected machine, it is windows
Trying to run pirated games will burn you occasionally, though.
But that's okay. My gaming PC is only for gaming. If it manages to get a virus that I can't quickly resolve, I'll just wipe it and restore from backup. And the biggest tragedy there will be that I won't be able to play games for a few hours. Meanwhile, my Linux PC that does everything important is completely safe.
Extensively.
I'm not going to lie the aur never made sense to me. If you are going to go to all that trouble why not just package it. Source packages are a thing.
The developers themselves are often not the package maintainers. Before a package is published or updated in one of the official Arch repos, it has to be built, tested, and sometimes patched (which is why you see a -1, -2, etc. appended to the package version), in order to work correctly not just on its own but in an Arch system with Arch packages that it is likely to encounter. The process is not as thorough as Debian for example, but it's still the responsibility of the package maintainer. If the package is still in early development, deprecated (e.g. wine32), an out-of-tree kernel module (e.g. xpadneo-dkms), or is meant to be built from the latest available commit (any number of *-git packages), the AUR is a convenient way to share PKGBUILD files rather than have the user build the software manually based on a readme, if it even includes build instructions. The PKGBUILD is then ingested by makepkg, which both configures the environment and builds the software, and outputs a package that can then be installed and managed by Pacman.
The caveat is that packages built from the AUR are not vetted by any package maintainers. They can have bugs, they might depend on outdated or no-longer-existent packages, or might contain malware.
it makes sense to me. remove as much friction from the publishing process as possible, so you get a huge amount of packages. this incident just shows they removed a little too much.
there are so many niche packages on the aur useful to so few people that nobody would go through the official process to properly package, test, and maintain them.
for example: vscodium is a fork of vscode, but microsoft disables the marketplace for it. the vscodium-marketplace package from the aur adds it anyway. i don't think any regular repos have these kind of hacks and patches available.
I found it kinda funny that enabling the marketplace in VSCodium was your example here, given how much of a vector for malware that is itself. It's malware all the way down.
You can download .vsix extensions from the marketplace and import them into VSCodium manually just FYI. And it won't auto update so it will save you next time a supply chain attack inevitably hits and starts infecting new versions. Assuming the downloaded version isn't infected in the first place of course.
Not to discredit your point about the AUR as I use it plenty myself but for this specific case is there a reason to use vscodium on arch since they ship code as an official package which has a marketplace?
Iirc, isnt that just a build right out of the ms repo? So all the telemetry would still be there by default, which vscodium removes. If I am remembering right, that would be the best reason IMO.
https://gitlab.archlinux.org/archlinux/packaging/packages/code/-/blob/main/PKGBUILD
Seems like it, but isn't that the same what vscodium does? https://github.com/VSCodium/vscodium#why-does-this-exist
Unless i am misunderstanding?
I don't really use either (outside of work scenarios where its going to be regular VSCode on windows anyway), just going off memory here, so I'd need to check too.
Doing a bit of looking, per vscodium folks:
They are very similar. Code-OSS is what you get when you build vscode from source. VSCodium is essentially just a build script that automatically builds from source when MS cuts a new release and then uploads the binaries here to GitHub. In that sense it is mainly to save time.
Additionally, VSCodium turns off telemetry in the build process, and rewrites some of the deeply nested telemetry URLs to go nowhere in case something in the codebase tries to send info back to MS. So that is a small difference that a standard build of Code-OSS would not have unless it was done manually.
I'm not sure how the packaging was done to get Code-OSS into Arch, so it's possible there are other differences with the Arch version specifically.
It just seems odd to me if there is no maintenance why not just build a package yourself from the devs provided source code? Maybe I'm just an old man but it seems without the on going maintenance it would be about the same as for example using buildpackage and apt-build on Debian but that is a local repo for just me. So if something goes wrong it only affects me not the whole internet.
Source packages are a thing.
AUR is a repository for source packages (in Arch it's called PKGBUILD) from users. You can write PKGBUILD yourself or just download it from AUR if someone already made it.
It bothers me that the movie this meme is based on removed the head rests. Smh my head.
Every movie does that. Just how they remove helmets from bikers and armor. Gotta see the actors beautiful face after all.
What's even worse is the helmets with lights on the inside so bright all the character would see is their own reflection
And loose their darkness vision and looking at some of those SciFi space helmets, basically completely blinded.
Star trek would not make it through first season if they wore ev suit every time they beam down...
shake my head rest
It's a metaphor for how AUR removes security guardrails.
Back when I was learning arch they made sure you understood AUR is an option, it was never a good option. Even then the risks were just not worth it.
My understanding the AUR was it was supposed to be a “here’s how I made this work.” But it gets treated as a generic repo all the time so…this.
I use aur, extensively, wasn't impacted by the supply chain attack cause I read the diffs.
Be real for a second,
Did you, or did you not, manage to review a diff, and say "no, that looks fishy".
Do you really think you are immune from compromised binary AUR packages thats being downloaded straight from GitHub? Sure, now it's not only the AUR that's bad, but in the end of the day, a malicious binary did arrive at your computer.
Let's say that you don't use *-bin packages, and only download from compilable source, are you immune from the strategy that the state actor who caused CVE-2024-3094 used to compromise packages?
in the end of the day, a malicious binary did arrive at your computer.
No, it didn't.
I'm with Cubit on this one. I updated some AUR packages last week. I always do a quick skim through the pkgbuild, and I always check the diffs with respect to my installed version. Auracle clones the git repo for the package, so it's easy to check. It takes more work and, granted, it's a reason they'll stay outdated for longer. I updated 5/34 foreign packages. The others are just not worth it to update every time. And, personally, I have had PKGBUILDs that looked fishy, forgot the functionality I needed, were badly written, wrong dependencies,... and, after looking for alternatives, I just rewrote myself.
When I learned of the attack I did go and recheck those packages, but they were not impacted... I don't do much node things, so if a node-related package was doing an npm install I might have missed it. But the commit author changing on the git diff I think I would have spotted. So if the attack was more sophisticated and was context dependent, using plausible commands, setting same git committer names, (ab)using files upstream, etc. Then yeah, I might get pwn'ed. But not like this.
Binaries from aur is asking for trouble, unless you absolutely trust the upstream. E.g. Microsoft, Amazon, ... You can clearly see it in the PKGBUILD. With -git packages, you need to be doubly aware, but if I need it, the alternative is I clone and install it myself, so not much security and probably frustration is gained.
The xz attack was on a different level, and if I remember correctly, never hit the arch main repo, by pure chance of not being a target. I trust the arch main repo's. The day a key gets stolen, a lot of people will be impacted, so let's hope this aur thing didn't compromise more high profile maintainers...
Also, we're talking about the AUR, not about upstream. I'm not reading all patches on all main repo packages. And if I wanted to build everything myself I'd be using Gentoo.
I do understand some people don't want to give the time to all these steps, but the alternative for me is just too bad. It's a time/security trade-off for which everyone sets the weights differently.
Why is adoption a thing in this way though? People compare AUR to github which seems very apt, but on Github no-one can come and take over the URL of an abandoned repo for rhemselves, if someone wants to start maintaining and the old owner is MIA, they have to make a fork. Why doesn't AUR work the same way but instead allows anyone to take over any abandoned project with no checks?
The forking option wouldn't work as well as it does on github because AUR packages are not namespaced like GitHub repos, e.g. communism/mypackage; instead it's just mypackage. So if adoption required a new name you'd have mypackage-cont, mypackage-cont-cont, or whatever. And it wouldn't really be possible to introduce username namespacing because AUR packages are just Pacman packages that are community-contributed rather than official, and Pacman, like most package managers, doesn't namespace their package names; firefox is just firefox rather than, say, mozilla/firefox. Some AUR packages get added to the official repos so when you do, e.g. yay -Syu, you'll then install the official package if you previously had the AUR package installed as it has the same name.
There isn't a perfect solution. Even if package adoptions were moderated, someone could take over a package and initially push a genuine commit, and then their next commit is malicious. Reviewing every single AUR commit would be incredibly labour-intensive. Possibly you could add automated checks for commits that suddenly add an npm install or other suspicious command with regex, but attackers could just get cleverer about avoiding those regex checks. Imo the best solution is just more widespread warnings about the fact that AUR packages are community-contributed with no guarantees of safety (e.g. on the Arch wiki where it sometimes suggests users install AUR packages), and AUR helpers forcing users to read PKGBUILDs before installation.
I use malware btw
I'd just like to interject for a moment. What you're refering to as Berkeley Software Distribution, is in fact, Unix or as I've recently taken to calling it, Ma Bell Berkeley Unix
Like saying as a widows user. "I got called by Microsoft "
Is this referring to some specific event or is it just a general warning about AUR?
I use AUR for "legacy" NVidia drivers btw
It's referring to those unfortunate findings
The specific event is the cause for the latest Arch News entry.
To be fair aur should be merged with nix or something to share efforts and be cross platform.
There is also appimages, if used as flatimage which uses bubblewrap as sandbox even if there is malware its impact would be minimalized
A lot of people probably won't like this, but personally I feel like Arch is a terrible OS from an average user's perspective. It offers nothing notable of value to its users, while making sacrifices in critical areas.
Unstable as hell and constantly breaks for no reason. On top of that, it's seriously insecure, as shown on exhibit A. It's not the first time, and it won't be the last.
Why not use Mint, Fedora, Zorin, Pop!_OS, or any of countless Linux distros that work perfectly and don't suffer from Arch's issues?
Note: I'm not an OS developer and mean no hate towards Arch devs or users. I'm simply speaking from a user experience perspective.
You said Ubuntu three times. /s
AUR is supposed the last resort, after distro repos, building from source, Flatpak, and Appimage. Ubuntu's equivalent to the AUR would be PPAs.
Personally, I have fewer problems gaming on Arch than any other I've tried.