Kind of blowing it out of proportion.

Does anyone know if yay gives 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

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)

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 PKGBUILD files 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.

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?

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.