As always a fair reminder to not install random 3rd party packages/libraries/applications without reviewing them, especially when there is zero vetting. Luckily this was constrained to AUR, which basically is a free-for-all package repository, with users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories.
`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.
> users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories.
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?
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.)
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 :)
>`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.
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.
> 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.
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.
I cringed hard when some people started to make pacman wrappers that could install from AUR directly.
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.
`yay` (one such wrapper) shows me the PKGBUILD diff on every update. The first time I install something I verify the URL, and check any install script etc. seems sensible; the vast majority of subsequent updates are changes to just version number & checksum. A typosquat attack would be very obvious.
(It's a bit vulnerable to it on first install, but so is 'just navigate to the project website [and click download]'.)
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.
For me, this tradeoff isn’t worth it. I didn’t switch to Linux so that I can waste time going to websites and clicking “download” to update my programs like a Windows user.
The pacman wrappers you mention are crazy, though.
You then get the advantage of the OS’s package manager accounting for everything, however. It’s quite nice to not wonder whether there’s random stateful detritus throughout your system and what it might be affecting. (OK, to be honest there still will be, but much less of it, and a greater part of it will be attributable.)
I think it's also a bit of a testing ground for the main repos as well. I maintained the `ruby-build` AUR package for a couple of years after the previous maintainer wanted to step down, but they eventually added it to the main repos and now it's maintained by one of the official people. (I don't recall ever having to do more than paste in the new release tag into the PKGBUILD each time and then generate the new .SRCINFO and checksums in terms of actual maintenance, although I'd test locally first before pushing of course).
I only have a couple of things in /opt/ and some manually installed fonts, and vim plugins in my home.
Everything else that I don't use often lives in the original cloned git repo in /home/projects and never really gets installed.
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.
The AUR is user supported and thus malware sneaks into packages all the time, although admittedly not to this scale. Still, it's pointedly not secure and has always had "here be dragons" signs plastered all around it.
There are definitely LTS distros where the official packages are not updated ASAP. Npm lets package authors publish new versions to all users immediately. Anything that doesn’t allow that is better. Some distros only incorporate patch/security updates for example.
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
> 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.been infected with malware
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.
Could we be heading towards a world where it's just more secure to write inhouse software again, only now with AI agents? Not closed source per se, but 'own source'?
The endgame is to generate a binary image for an entire single-purpose OS/unikernel that does exactly and only what you require of it. No source to open or close.
This is something that worries me with a distribution like Alpine Linux.
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.
I’ve made a point of not installing any AUR packages. It’s really tempting when there’s a package that’s not available via pacman, but at the end of the day I’d rather build from source myself or use a docker image.
Not even "packages" in the distro sense. You can't use software installed with Arch to install this stuff via any path that isn't isomorphic to rebuilding the package yourself.
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.
While this makes Arch Linux look bad right now, I recall how many years ago Gentoo was leading the pack with regards to having many clever people on board. Then came Arch Linux and eventually it put Gentoo as a second tier distribution. Arch has a lot of momentum; I myself am using Manjaro right now, primarily because it makes many things - including compiling from source - simple. As simple as Slackware, before Slackware fossilized (it's still alive of course, but just look at the most recent ISO release, then you'll understand the problem; when a distribution is no longer able to release .iso files, then it is in my book dead).
As always a fair reminder to not install random 3rd party packages/libraries/applications without reviewing them, especially when there is zero vetting. Luckily this was constrained to AUR, which basically is a free-for-all package repository, with users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories.
`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.
> users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories.
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?
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
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 :)
>`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.
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.
> 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.
So from a quick read, it seems it installed "atomic-lockfile", "js-digest" or "lockfile-js" from npm. A list of affected packages is here [1].
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.
[1] https://md.archlinux.org/s/SxbqukK6IA
I cringed hard when some people started to make pacman wrappers that could install from AUR directly.
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.
`yay` (one such wrapper) shows me the PKGBUILD diff on every update. The first time I install something I verify the URL, and check any install script etc. seems sensible; the vast majority of subsequent updates are changes to just version number & checksum. A typosquat attack would be very obvious.
(It's a bit vulnerable to it on first install, but so is 'just navigate to the project website [and click download]'.)
But it's one middle man less.
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.
For me, this tradeoff isn’t worth it. I didn’t switch to Linux so that I can waste time going to websites and clicking “download” to update my programs like a Windows user.
The pacman wrappers you mention are crazy, though.
I get it, but you only need to do that for the odd cases of packages not present in the official repo (not that common at all for me at least).
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.
You then get the advantage of the OS’s package manager accounting for everything, however. It’s quite nice to not wonder whether there’s random stateful detritus throughout your system and what it might be affecting. (OK, to be honest there still will be, but much less of it, and a greater part of it will be attributable.)
I think the existence of the AUR puts less pressure on the official repository to have all popular software.
I think it's also a bit of a testing ground for the main repos as well. I maintained the `ruby-build` AUR package for a couple of years after the previous maintainer wanted to step down, but they eventually added it to the main repos and now it's maintained by one of the official people. (I don't recall ever having to do more than paste in the new release tag into the PKGBUILD each time and then generate the new .SRCINFO and checksums in terms of actual maintenance, although I'd test locally first before pushing of course).
> typoquatting
Perfect demonstration!
This sounds like your update process is quite involved then. Or do you just not do it?
I only have a couple of things in /opt/ and some manually installed fonts, and vim plugins in my home. Everything else that I don't use often lives in the original cloned git repo in /home/projects and never really gets installed.
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.
I’m not on Arch Linux, but I am on NodeJS a lot, which frequently suffers from similar types of attacks.
Who is doing package management right these days? Who is doing it securely?
The AUR is user supported and thus malware sneaks into packages all the time, although admittedly not to this scale. Still, it's pointedly not secure and has always had "here be dragons" signs plastered all around it.
Arch is fine if you do not use AUR. If you use AUR check everything.
Most distros are too. All the big distros have pretty good track records.
There are definitely LTS distros where the official packages are not updated ASAP. Npm lets package authors publish new versions to all users immediately. Anything that doesn’t allow that is better. Some distros only incorporate patch/security updates for example.
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
Running external code will always be a risk. Even if it is not intended to be malicious it could still have issues that compromise security.
Read the source. If you don't have the time then you shouldn't run the software.
It's a lost battle.
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.
Min Release Age of 7-30 days covers the majority of potential issues with 0 effort.
All major Node package managers should support it by now.
Prom was the best IIRC, yarn second, but even npm is catching up
> Who is doing package management right these days? Who is doing it securely?
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.
> 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.been infected with malware
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.
Could we be heading towards a world where it's just more secure to write inhouse software again, only now with AI agents? Not closed source per se, but 'own source'?
The endgame is to generate a binary image for an entire single-purpose OS/unikernel that does exactly and only what you require of it. No source to open or close.
Seems cheaper (and so far more robust) to have an agent audit downloaded code
this
This is something that worries me with a distribution like Alpine Linux.
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...
I’ve made a point of not installing any AUR packages. It’s really tempting when there’s a package that’s not available via pacman, but at the end of the day I’d rather build from source myself or use a docker image.
As I undertood it this was mostly orphaned packages?
That's correct, orphaned packages could be adopted seemingly automatically, so someone did and then published malware in bulk.
Yes and honestly super kudos to paru's creator for the nagging warning about installed orphan packages that made me remove them immediately.
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?
Not even "packages" in the distro sense. You can't use software installed with Arch to install this stuff via any path that isn't isomorphic to rebuilding the package yourself.
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.
While this makes Arch Linux look bad right now, I recall how many years ago Gentoo was leading the pack with regards to having many clever people on board. Then came Arch Linux and eventually it put Gentoo as a second tier distribution. Arch has a lot of momentum; I myself am using Manjaro right now, primarily because it makes many things - including compiling from source - simple. As simple as Slackware, before Slackware fossilized (it's still alive of course, but just look at the most recent ISO release, then you'll understand the problem; when a distribution is no longer able to release .iso files, then it is in my book dead).
"linux has no malware, windows bad boooh"
"linux has a central package manager with every app that you need, so you don't need to install random apps from random websites like on windows"
Who's on Arch Linux btw?
How bad was it?
1,500 packages out of 107,000 so pretty bad, ameliorated by only affecting installs of those in a window of a few days.
AUR comes with a warning that its up to you to check what you install from there.
I was concerned at headline, then saw "oh just AUR"
Next up, "millions of malicious packages still not taken down on internet"
I wonder what typical AUR usage looks like. I apparently have 27 packages installed and last updated one in November.
There's more than one way but this lists packages not installed by pacman itself:
Only 237 on my 12 year old system but I rarely update AUR packages and usually try to remove unused ones before updating.