The Model and Its Limits
The Arch User Repository operates on a deliberately minimal infrastructure: a contributor submits a PKGBUILD — a shell script specifying where to fetch source, how to build it, and what dependencies it carries — and any other Arch user can download and run it. The Arch Linux project does not audit these scripts before publication. Trust rests instead on community review of the script itself, the comment history attached to each package, and the accumulated reputation of the maintainer's account.
That model has produced something extraordinary in scale. As of mid-2024 the AUR hosted over 85,000 packages, dwarfing the official Arch repositories and providing build scripts for software that would never attract a distro-employed packager. The comprehensiveness is real; so is the exposure.
The mechanism of risk is not subtle. A PKGBUILD can specify any download URL and can run arbitrary code during the build phase, before a user's package manager sees the final artefact. An attacker who gains access to a legitimate maintainer account, or who registers one and slowly accumulates install counts under a convincing name, has a direct path into the build environments of every user who runs the package. The pattern mirrors the supply-chain attack dynamic documented in the npm ecosystem: trust accrues to an identity, and the identity is the target.
Documented incidents are not hypothetical. In 2018 an AUR maintainer transferred three packages — including acroread — to an account that then modified the PKGBUILDs to include malicious code. Arch Linux's response was to remove the packages and issue guidance reiterating that users should read every PKGBUILD before building. That guidance is correct and also structurally demanding: it places the entire verification burden on individual end-users, most of whom are not, in practice, auditing shell scripts line by line before every system update.
The AUR's defenders note, accurately, that the repository's design is explicit about this. It is not a curated store; it is a community scratchpad with version control. The Arch wiki states plainly that AUR packages are unsupported and that use is at the user's own risk. What the model cannot resolve is the gap between that formal disclaimer and the de facto treatment of popular AUR helpers — yay, paru — as equivalent to official package managers, a conflation that experienced maintainers discourage and most new users perform anyway.
The deeper question the AUR poses is the same one the xz backdoor raised at the compression-library level: how much of the software supply chain runs on social trust that has never been formalised, funded, or audited, and what happens when that trust is deliberately exploited rather than merely strained?