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.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.
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)
Totally but I also want to point out that reviewing changes is a lot easier than the first review. Ideally it has just a couple of lines changes and they are just version changes most os the time. It also does not help the existence of “pacman for AUR” that just encourages all the bad behavior, they encourage installing a lot of AUR packages without thinking twice, update without checking and to trust it or think it is the same as the maintained main repos since I think most if not all AUR packages also work as a pacman frontend.
The user was never supposed to rely on a lot of AUR packages and if you do maybe you better of with a distro that does package what you need or that the software authors package for.
Sure reviewing changes is easy. But the problem is that it is still a review. You need to have an understanding of what exactly is being done and to account for any oddities that may or may not be because of the quirks of upstream. That’s why I mentioned that AUR trust models should be made like pacman for most helper. We trust the maintainer of Arch so why can’t we trust other people too? Take PPA, the trust model is exactly that. You trust the maintainer. At the very least make it an option that you can choose on first run
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?
The AUR should not be thought of as a package manager repo. It should be thought of as a pastebin for pkgbuild scripts, i.e. build instructions. Running them without looking is the equivalent of blindly copying shell commands from stackoverflow.
If you are thinking “I want to install this package I found, it doesn’t exist in any repo, but their build instructions are complex and don’t have instructions for arch,” a pkgbuild is a great resource. At the very least you can read someone’s pkgbuild to see what dependencies and build steps worked for them (in the same way that you can disect a shell script line-by-line to understand what it’s doing).
The only official way to use the AUR is to manually download a pkgbuild file and use manually run makepkg to execute it. All the other tools that turn it into a convenient repo source (ex. yay, paru, pamac) are unofficial.
Cachy’s new package manager, Shelly, which is awesome, BTW (writing about arch or derivatives without using BTW is against the law, remember.) does checks on AUR packages when installing or updating. Zoey rocks!
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.
Does anyone know if
yaygives me the ability to hook my own tool in to review pkgbuilds before accepting them? They argue that they don’t want to just give attackers access to a scanning tool, because all they’d do is just iterate on their pkgbuild until it reports “not detected”. But if yay gives me an easy way to hook in whatever tool I want, the attacker can’t be sure what tool to defeat. If thousands of people all run various tools, surely a few of them will spot the anomaly quickly.Edit: it looks like they’ve added this exact functionality in response to the attacks: https://jguer.space/blog/2026-06-15-yay-v13
Kind of blowing it out of proportion.
