Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

But many users don't. As far as I can tell, there is very little actual guidance about what to look for, not even to the extent of what you explain here, on the wiki. Users are told to check the PKGBUILD, and warned about AUR-helpers being dangerous, but in practice, it seems AUR-helpers are widely used, and many users likely just click through PKGBUILDs they won't be able to understand.

And, again, this attack was a relatively obvious one. Other attacks could be made much harder to notice.

Worse, distributions like CachyOS are being broadly promoted to a user base who can't be reasonably expected to check over AUR packages themselves. Unlike ArchLinux, those sometimes do seem to promote AUR-helpers. In some cases, those distributions are apparently including AUR-sourced packages in their actual repositories.

Questions about these topics often result in typical Archlinux hostility. And in some sense, that's understandable: there are other distributions that most users should be using, and the frustration of people using Archlinux who shouldn't be is wearing. It is nice to have a distribution that offers the flexibility and space for experimentation that Archlinux does. It's one of the reasons I use it on some of my machines, while at the same time recommending against most others using it.

To some extent, this is just a wide cultural difficulty with Linux, and there isn't a clear answer. On one hand, you want enough gatekeeping to keep users away from potentially dangerous systems they have no interest in understanding, and that they'll rely on without understanding in situations where they shouldn't. On the other, you don't want to keep out users who are interested in learning.

There’s bits and pieces of this in place with immutable distros, Wayland, and Flatpak but notable holes remain. The biggest one is that sandboxing is tied to the package format which I think is a mistake. Sandboxing and access permissions should be a system-level thing so even arbitrary binaries can’t easily slip through the cracks.

This wouldn’t fix the problem entirely, but it’d greatly limit the blast radius and make users of the distribution a less juicy target.

It's crazy that all it takes to become a maintainer of a package is to flag it as orphaned, wait 2 weeks for the original maintainer to fail to respond because they're on a holiday, and BAM! - the attacker can gets assigned as a maintainer and can now ship spicy updates.

That's perhaps the intent ideally, but in practice, it feels like AUR tends to be (a) niche, esoteric things that will never be anywhere outside of AUR, even if they could, or (b) installation methods for proprietary/otherwise non-open packages that can't be.

The latter seems to a major popular use of AUR: sorting packages by popularity or votes comes up with lists that seem to be mostly these. And that's likely a significant draw for non-technical users. If you want to install things like Dropbox, Chrome, VS Code, Minecraft, Zoom, Slack... they all show up in AUR. By their nature (usually extracting packages from upstream installation methods), they tend to be more complicated than generic AUR packages. They are also often quite a bit more convenient than using the upstream packages, which might not interface well with Archlinux, might only be available with installation methods that clobber things, might be deb/rpm only, etc.

I wonder if it would make sense to have a more trusted/vetted repository of these sorts of scripts, separate from core repositories but also not as free-for-all as AUR. That might go a long way toward keeping non-technical users from being drawn to AUR.