This is like saying a user who clone a random git repo is not to blame and git-scm should do more to prevent cloning of malicious repos. If it is not official, it is your job to review, if you dont like it, use iOS instead of Arch Linux.

If you crash your car, you are liable for the accident. If you aren't ready for that, take the bus.

More power = more responsibility

As an arch user, I would always skim the PKGBUILD file of AUR packages to see if they install the software they claim to install from official sources and if there's something obviously fishy.

Ask an LLM to assess the package and do a web search for you. Nobody is installing tens of packages a day, you can take a few minutes to consider what you are installing. This isn't blaming the user, it's basic digital hygiene.

An archlinux package build file is just a shell script. It's pretty easy to take a look and see if all the manifest info is right and it doesn't do more than ./configure; make; make install DESTDIR=$PKG or whatever. If you're building random software using random instructions from the internet and don't make sure they're not malicious, you only have yourself to blame when you catch something. Actually reading through the source files for vulns is something best left for automatic detection, checking the build script is basic.

It’s free lines of code on the internet that you are going out of your way to run on your own machine.

Lets take two real and random examples, and I'll share what I'd look for:

First, very easy one, we want to install Brave, so we find https://aur.archlinux.org/packages/brave-bin. All the dependencies are in the official repos already, so those we trust already, you open the downloaded PKGBUILD and you find it's downloading a binary from github.com/brave, you check to see it's the official GitHub profile/organization that you expect. Quickly scan prepare/package for anything out of place, like downloading more files not defined in "source" or whatever. In this case, "suid sandbox" stuff should make you investigate closer so you understand what that stuff does, many things related to Chrome has things like that. That AUR package also has a brave-bin.sh, so a look through that would make sense. AFAIK, everything checks out, this is literally just downloading the official release from GitHub, and extracts it into the right place, so if you trust the GitHub org/user, you can trust the PKGBUILD. The PKGBUILD also seems to be officially maintained by Brave themselves, so probably already there you can verify the AUR user and be done if you feel lax.

Second example is unofficial package, https://aur.archlinux.org/packages/lmstudio-bin, maintained by noureddinex and created by MadGoat, neither which seem official at a glance. Read through the comments to see if anyone else flagged anything, seems fine so again go read the source of the package and the PKGBUILD. PKGBUILD seems standard, downloads something from "installers.lmstudio.ai" so first thing to check is if that's actually the official website, so use search engine to find official website, copy the URL of the download, verify it's the same. In this case, lmstudio.ai is the real website, but download URL on website ends up being "https://lmstudio.ai/download/latest/linux/x64" in the HTML/DOM, so use "curl -v -L $URL" to see redirects, and then we've confirmed installers.lmstudio.ai is actually what they use for official releases. Read through "prepare" and "package", both seem standard and fine, then look through the rest of the files, all of them seem fine, mostly maintenance scripts for the AUR package itself. Package seems fine as a whole, and we could install it, if we're willing to review it again on upgrades in the future.

This is basically all you have to do. Writing what I did while doing it, made each "review" take maybe 5-10 minutes, and it isn't harder than that, regardless who the user is. You just need to know what to look for, and think how you'd "officially" install it anyways. And if what the PKGBUILD differs from what you'd imagine an "official install" would do, investigate if it makes sense and if not, don't install the package, maybe leave a comment for others in AUR to dive deeper.

As someone already explained in a sibling comment, Arch Linux AUR packages are simple shell scripts that download source code from upstream, apply patches and install.

I review them every time I have to install from AUR.

That is a terrible way to run a package repo in this day and age.

Maintainers need to have some level of vetting, and should own a repo or three for a while to establish a track record, before they get to blast out contributions to 100 of them without any review.

Idk. Arch does have official repositories that are actively maintained and vetted. AUR is for the vast amounts of random software that isn’t popular or important enough to be officially maintained.

I’m not sure how to find a balance. One reason to use Arch is to always have the latest software, especially if you’re gaming. (Need to run very recent kernels, GPU drivers, and DEs to support new graphics cards.) So that’s very different from other stable LTS distros which carefully pick the package updates they incorporate.

Anyways, I do agree package cooldowns and such make a lot of sense. Package managers should be pulling out the stops on all the free controls they can implement. I can understand why anything requiring compute or maintainer time is a non-starter. (Sidebar: I don’t feel the same way about npm. Microsoft can afford to run malware scanners and analysis tools on npm packages.)

https://wiki.archlinux.org/title/Official_repositories

It's definitely a sign that popular packages should be moved from AUR to the official repository. I've got some stuff from AUR simply because it's something I need and that's where it is, and I never really verify it's safe; I just trust it blindly. Clearly a bad idea. I guess I should learn to avoid AUR and when I do use something from it, we more aware it's an exception and I need to check it more thoroughly. That's something I normally only do only for stuff that's neither from AUR nor the official repo.

> Some other controls could at least alleviate the problem

The biggest one I'd suggest they change immediately is remove the ability for anyone to just take over an orphaned package. That's a crazy policy, to me.

It should require you to fork it & resubmit, not take over the original.

Then they can go through and do purges of orphaned packages that are beyond a certain age.

Personally, what you suggest would defeat the purpose of the AUR, and what you describe is already applied to the official packages. If you want only the safe and stable stuff, don't use random packages from AUR :)

Packages in the AUR have some number of maintainers. When a maintainer no longer wants to maintain the package they can disown it, and when all maintainers do so the package becomes orphaned. An orphaned package can then be adopted by any user.

At any time there's a large number of orphaned packages in the AUR, and the attacker(s) targeted those.

> But I admit I don't really know how AUR works

It's basically GitHub (in terms of "User's generated content") but tailored and specific to Arch/Arch-derived distributions. Packages have owners, but everything is very "freeform" in general on the AUR. It wasn't uncommon you could be added as a maintainer by just sending a mail to the current maintainer, since it's basically "Hey let me contribute to your repository" (simplified), today people keep track a bit better and avoided that I've seen. But still, it's on a individual basis.

Just like GitHub, AUR is completely devoid of peer-reviews, users uploads their own PKGBUILD and share with others, and the expectation is that users review stuff before they install it, just like on GitHub, or just like on the internet in general.

Not all tools are made for inexperienced people. Not everything is idiot proof. This is OK!

In my experience using the AUR:

1. when you first install the package you can read the build script (and you should). These are in a very standard structure, and if the one you are reading is weird and complicated consider not installing it. No one is forcing you to. Almost every build script I read just downloads a build from a tagged github release.

2. when you get an upgrade you are shown the diff. For almost every AUR package I use this is literally just changing the $VERSION variable and the subsequent $HASH of the download. It is trivial to see if anything (in the AUR script) is happening that is sneaky.

It's really not that scary. And if it's considered scary, there are literally dozens of other linux distros (not to mention Windows or MacOS) you could be using instead.

> What review should users do?

The same sort of review you'd do if a stranger sends over a project and says "compile and run this" and you actually want whatever it's supposed to do, so you start looking through it.

> It appears that, in some cases, these were adding npm as a dependency and installing atomic-lockfile, and in others, these were adding bun and installing js-digest

That's very suspicious if the package you're about to install doesn't seem to actually need those things. Since "AUR === random strangers on the internet with zero trust", then you need to pay attention to those sort of things.

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

Yes, indeed. Same as if you come across a random C++ project on GitHub with 2 stars, do you just pull down the source and compile willy-nilly? Probably not, you carefully inspect it can actually do what you want, how it does it, and so on. AUR is basically like GitHub in this case, zero peer-reviews and users fully responsible for whatever they install.

> At that point, what is AUR actually offering that installing the upstream package isn't?

PKGBUILDs, so you don't have to write them yourself. Not more, not less, just a central place for random strangers to share PKGBUILDs that may or may not work for others.

> At that point, what is AUR actually offering that installing the upstream package isn't?

It produces package files that pacman can use. Sure, you can curl|sh or whatever, but that's a good way to litter stuff all over that you can't track or uninstall cleanly.