All of that wouldn’t have any effect if the aur helper mimics the model of pacman. Trust the maintainer, not the build script. By requiring users to review PKGBUILD every time it changes, it encourages laziness. But by requiring the review only once then trusting the maintainer, it helps a lot because the only way an attack can be done is directly attacking infrastructure (pushing malicious script bypassing the auth) or hacking the account (author turning malicious). Both of those are hard with a properly configured system or not worth it because it requires a long game (like those of xz attack)
I’m still quite new to Linux, using CachyOS (arch). What’s the best alternative to AUR, I saw someone mention Flatpak because it is at least somewhat sandboxed. Anyone have some best practices given AUR doesn’t seem to good of a choice?
Stick with verified flatpaks on flathub (they also host unverified packages, avoid those), and Appimages directly from the software maker’s site, if they offer them.
The Gnome Software Store and the Mint software store both have the option to not show unverified flatpaks, which I would suggest using.
Arch is not the only distribution that has a service for providing “use at your own risk”, unreviewed, user-submitted content; Fedora has Copr, the openSUSE project has the Open Build Service (OBS), and Ubuntu has Personal Package Archives (PPAs). Each of those services allow a person to sign up without any review process and build packages for download by other users of the distributions.
However, there are important differences between those services and the AUR. They provide a build environment that is similar to the ones used for the official distribution packages, and do not allow pre-built binaries or proprietary software. The model for Copr, OBS, and PPAs is that a user creates a project under their own user namespace; users have to add each repository from one of those services separately.
For example, niri creator Ivan Molodetskikh maintains a Copr repository for Fedora users who want to run the tiling Wayland compositor. To install niri from Copr, a user has to enable that repository specifically. It is possible for other Copr users to create a similar project under their own namespace, but it is not possible for another user to take over Molodetskikh’s repository unless they compromise his credentials. A would-be attacker could create a malicious fork on Copr and try to lure Fedora users to add that package repository to their system instead, but the attacker cannot simply pick up an orphaned Copr repository to compromise users who have already added it.
The AUR, on the other hand, is much more relaxed about ownership; the
PKGBUILDfiles are all maintained under the AUR namespace. The rules state that, when a new maintainer takes over an AUR package, they are supposed to add their own information as maintainer and then list the prior maintainers as contributors. That, however, is taken on trust and (as seen with the current attack) can be easily abused.Thank you for explaining the differences. I’ve had several heated arguments with several users on this community where they tried to compare the AUR with these other solutions you mentioned. There’s a big difference between them. Namely regarding who controls the user repos. You explained the differences very well and I hope others understand better now just how AUR is dangerous and how this is negatively affecting the reputation of Arch and Linux in general with the wider public.
It really should be shut down for Arch’s sake. If people want to provide a package with certain modifications, just let users get it off your git repo and build it themselves with the proper instructions. It’s not that much safer, but just enough that it should prevent this kind of widespread problem.
It really should be shut down for Arch’s sake.
I think it should really be split into two parts:
- The more widely used packages should be moved to an official repository with review procedures. Perhaps the (quality) requirements can be lower, but these must be reviewed by trusted people.
- The remaining packages should be moved to user namespaces, like the other user-package repos do. That will at least prevent (most) takeover attacks.
If people want to provide a package with certain modifications, just let users get it off your git repo and build it themselves with the proper instructions. It’s not that much safer, but just enough that it should prevent this kind of widespread problem.
That’s already the recommended path.
It really should be shut down for Arch’s sake.
A long time ago I chose openSuSE over arch because of (among other) me being concerned with the lax use of the AUR by the community. One should just be somewhat mindful of what that thing is – it is pretty much the equivalent of clicking links on the web to download software for Windows. I think it should be used for what it was supposed to be.
The AUR was created to organize and share new packages from the community and to help expedite popular packages’ inclusion into the extra repository.
Maybe arch should adopt something akin to open build service and openqa to more quickly grow the extra repository which then can be monitored better?
I’m afraid that the level of security needed to safeguard such users would be a dystopian nightmare. I’m sure a lot of them are the kind to just download and install random crap on Windows too. Once again, freedom and security comes at odds.
After the recent attack, I setup aurscan (mentioned in the article) with a locally hosted Gemma model to scan package builds and install files.
Hard to know how well something like this will actually work. So far it’s cleared most updates I’ve thrown at it, with one false positive/warning.
