I think this stance should be re-evaluated. Arch Linux developers are doing a fantastic job and I am personally thankful to them - this is not in any way critical of them. And while I don't see an easy solution here, I just feel that the time of "warning users" is long gone with how much supply-chain attacks are ramping up these days.

Some other controls could at least alleviate the problem. Perhaps some form of peer-review and grace period before publishing could help here?

What review should users do?

It appears that, in some cases, these were adding npm as a dependency and installing atomic-lockfile, and in others, were adding bun and installing js-digest. /This was a mass attack against mostly low-use/orphaned/etc packages where maintainership was taken over or a different user uploaded a new version (itself a very simple, low-notice, low-oversight process), and many of the packages clearly had no connection to Node.js at all, so a user who knew enough about each package, and knew what npm was, might notice the oddity in the package, if they reviewed every line of the PKGBUILD, then reviewed the install scripts.

But legitimate AUR packages for packages connected to Node.js also use npm, for example, and at times, use npm install. A user would have to be familiar enough with Archlinux's build system to understand the difference between each part (eg, build() vs install scripts). They'd have to review every PKGBUILD, every install script, and every patch of every AUR package they install. For packages that actually do use npm/bun, they'd have to be familiar enough to know what uses were legitimate and what uses were not, and might have to be up to date on compromised dependencies. And this is still considering a mass attack that was not particularly hidden. Attacks could be made much harder to find.

Asking a user to safely review an AUR package essentially seems like it is asking them to fully understand not just the build process, and programming language, of the upstream package, but also all details of Archlinux's build system. At that point, what is AUR actually offering that installing the upstream package isn't?

There is perhaps some room for LLM analysis here: Opus 4.8, Kimi latest, and even Qwen3.6 27B quickly catch at least the current round of malicious packages in my tests. But a motivated attacker could make that more difficult, or dangerous. And a user could also just have those models install the upstream package as well, with less risk.

AUR comes with a warning that its up to you to check what you install from there.

The pacman wrappers you mention are crazy, though.

Perfect demonstration!

So with a dozen of various systems running arch/cachyos for various purposes, 0 impact.

We seriously dodged a bullet though, should we have some kind of AI spotting shady activity before it hits the userbase?

This was the AUR repository, which is the community-maintained soup of non-distro packages. They're packaged using the same tools and technology, with the intent that they can be easily validated and promoted to core stuff in the future. But they aren't really "Arch Linux". You need to deliberately enable and install tools to pull stuff from it.

Think of this as Steam or Chrome. You can install those on Arch, and people do, but if Chrome extensions or Steam games suffer an incident like this you don't blame the distro.