What Linux distribution^1 has the highest percentage of users who compile from source
Is it Gentoo
1. Besides Linux from Scratch
It is hard to avoid a package like chromium [0] or firefox which are in the "community" repo. Now have fun check it at every update, this is not practically feasible.
For the web browser one can say we should use Flatpak anyway but there are a lot of other apps like sway from the community repo that cannot be flatpaked.
- [0] https://pkgs.alpinelinux.org/package/edge/community/x86_64/c...
`rua` and other similar CLIs make it really easy to review the packages before installing them from AUR too, and if you are doing banking on the same computer, you really have no excuse not to review the software you depend on. Keeping the amount of packages low, only use what you need, also makes this a whole lot simpler when it's time to upgrade.
I've installed stuff from the aur before but most of the times I prefer to skip the middleman and just navigate to the project website. A premade pkgbuild is not convenient enough to take the risk of typoquatting or the tactical npm or pip dependency.
Didn't find any quick info on how to check a system, so I ran the following command to find foreign packages and some date related infos:
> pacman -Qmi
Check the output against the list of affected packages.
Then, you can also grep for those files in various locations: > grep -rl "atomic-lockfile" / --include="package.json" --include="package-lock.json"
> grep -rl "atomic-lockfile" ~/.npm 2>/dev/null
> grep -i "atomic-lockfile" /var/log/pacman.log 2>/dev/null
Don't know if the packages delete themself after they run. I just wanted to provide some basic commands, as all the other infos I found didn't provide any help.
Who is doing package management right these days? Who is doing it securely?
I never had a need for the AUR.
If I want a package not in the official repository I build it myself or if it has a binary release I will download it. this way i don't have to use root when building and can have program installed locally just for a single user which is how it should be anyway for most desktop use cases.
At least in this way there is one less level of possible malicious code insertion in developer -> user, vs develeper -> maintainer -> user.
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.
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.
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.
I'm willing to bet you yourself have read <1% of the source code currently running on your computers. Does this mean you have stopped using your computer(s)? How can you trust anything that happens on them?
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, these 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. They need to learn how to do this with, as far as I can tell, no real guidance: AUR itself, and the wiki's page on it, just warn that users should carefully review the PKGBUILD and install scripts, without giving any substantial guidance on what to look for or how to review anything. The warnings feel much more like liability-reduction than an attempt to be helpful.
At that point, what is AUR actually offering that installing the upstream package isn't? It feels like the suggested 'safe' way of using AUR would make it just as much work for the user, and require just as much knowledge, as either installing the upstream directly, or even making a package for it.
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, with less risk. If they want to use pacman for management, they could likely even have those LLMs generate a package, with less risk.
The pacman wrappers you mention are crazy, though.
(It's a bit vulnerable to it on first install, but so is 'just navigate to the project website [and click download]'.)
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.
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.
At any time there's a large number of orphaned packages in the AUR, and the attacker(s) targeted those.
Perfect demonstration!
Most distros are too. All the big distros have pretty good track records.
AUR is worse, in that there may not be official authors and you can take over releases of a package. Like, you’ll have random users publishing the release for some application that doesn’t have their own Arch release. And if that user disappears, someone else may take it over
Read the source. If you don't have the time then you shouldn't run the software.
All major Node package managers should support it by now.
Prom was the best IIRC, yarn second, but even npm is catching up
Everything will need to be run in a VM separated from your main desktop which should have your data and a minimal amount of apps.
Qubes OS was ahead of it's time.
The malware was limited to package sources that I understand to be disabled by default, if you're using Arch Linux. These package sources carry clear warnings that the packages they provide are controlled by third-parties and entirely unvetted by the distro maintainers. [0][1]
If your assertion is that any package management system that permits the installation of packages that aren't vetted by the maintainers of the -er- OS that uses that package management system is "not doing it securely", then the only one that's even vaguely "doing it securely" is Apple's iOS.
I'm of the opinion that permitting users of a general-purpose computer to install arbitrary software is a good thing, and is pretty much the entire point of a general-purpose computer. I'd call computers that make that effectively impossible "appliances". There's very definitely a place for appliances, [2] but seeking to turn every computer into an appliance is massively destructive.
[0] <https://aur.archlinux.org/>
[1] <https://wiki.archlinux.org/title/Arch_User_Repository>
[2] Reliable computers that you never have to think about because they simply never fail to perform the useful tasks they were designed to do are great.
`makepkg` will actively refuse to run if you are invoking it as root (unless you specifically invoke it with something like `env EUID=123 makepkg ...`).
> and can have program installed locally just for a single user which is how it should be anyway for most desktop use cases.
I do wish pacman would support a user level installations. It will refuse to install packages as non-root (which you can go around by using user namespaces and mapping yourself to root).
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.
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.
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.
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.
AUR comes with a warning that its up to you to check what you install from there.
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
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.)
I review them every time I have to install from AUR.
QBASIC. When you need a package you type it in from a magazine. Virtually anything you could ever need is only 1-12 weeks away.
Git repo have been attacked other times in the past, but a 500/1000 stars project still sounds more trustworthy than a user repository managed by randos with a couple of upvotes. I still use the aur for simple cases, but when I see aur packages depending on multiple other aur packages I immediately leave.
Of course the process breaks down for a large amount of packets, but I've never been in that situation. In part because the official repo is already large, and in part because I like minimalism.
If that even became an issue, I would manage a personal set of pkgbuild probably.
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.
Also if the software is downloaded in the form of a git repo, you only needed to checkout the new tag and rebuild, don't need your browser at all.
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.
Next up, "millions of malicious packages still not taken down on internet"
I think the issue is those repos being based on Arch though, not Arch itself.
I don't review updates to official packages on Arch, I don't think most people have time to do so, it's just way too much. Things change when we talk about AUR though, as those aren't vetted, those you need to take the time to review, otherwise you're basically installing completely unreviewed software from strangers on the internet.
That's where the whole "Not everything is idiot proof" thing comes in. The distribution is pushing the responsibility on users to vet what they do, across everything, not just installing AUR packages, so naturally this also applies to installing 3rd party software.
If you don't know what to look out for, maybe don't install stuff you don't know what it will do. Sucks as an answer if the distribution is looking to "Make it as easy as possible for every user" but that's not Arch Linux ultimately, it does ask you to care about things like that, if you don't want to, it might not be the OS for you. And that's of course OK and not something bad. I know this sounds like gatekeeping, but it's more of a culture difference than anything, and probably not even a problem.
> distributions like CachyOS are being broadly promoted to a user base who can't be reasonably expected to check over AUR packages themselves
That'd suck, but not the impression I've got from CachyOS. There is a FAQ entry that seems to get the gist of AUR correct, that it's basically random software from random users, nothing is assumed safe: https://wiki.cachyos.org/cachyos_basic/faq/#aur-safety-pract...
> this is just a wide cultural difficulty with Linux, and there isn't a clear answer
I don't think "a answer" is needed here. What some read as "gatekeeping" and "Arch Linux hostility" is in reality just a difference of culture, and that's not a bad thing. Some distributions are for making things "easy for newcomers" or some focus on "best UI and UX" and others "most barebones for experienced users to setup themselves", and all of them as valid as the other. The tricky (and slow/time consuming) part is that you have to try a bunch before you find which one(s) aligns with your own perspectives and ideas.
Ultimately, users can learn best together with distributions that align with how they think and want to work.
pacman -Qm
Only 237 on my 12 year old system but I rarely update AUR packages and usually try to remove unused ones before updating.Btw the official “vscode on Linux” instructions literally point to the community maintained AUR (same for nix).
The truth of the matter is the AUR is poorly maintained structurally, regardless of what companies officially support. Things like letting arbitrary people unilaterally take over orphaned packages is horrendously stupid.

The day started out with Arch Linux's AUR user-contributed repository seeing more than 400 packages compromised with malware. Now in ending out the day they believe all affected commits have been addressed. But it ended up being more than 1,500 affected packages.
It was bad enough when finding out more than 400 AUR packages for Arch Linux users had been infected with malware but now that number has risen to around 900 a few hours ago and now in the end at more than 1,500 user-contributed packages.
In an update a few hours ago, it was believed around 900 packages were infected by malware in this week's incident.
Then as of writing now, the last message in the thread over this security incident is noting that Arch Linux developers have deleted all the malicious commits they are aware of. Cited was this list that puts the number of malware-affected packages at 1,579! Tons of software in this user-maintained Arch Linux user repository were impacted by this nasty security incident.
Even at 1,579 packages listed, that final updated noted, it's a "list containing many (but not all) of the affected packages". Ouch.