You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. This really has always been the case; we've had discussion about this for well over a decade. People are always asking why there's no official AUR helper like yay - this is why.
A lot of people complain about Arch Linux being elitist, but the simple reality is it's a distro built for people who know what they are doing and don't need or want their hand held at every step of the way. This also means that if you break or compromise your own system by installing random AUR packages, it's your own damn fault.
All of that being said, the era of allowing anyone to adopt AUR packages might be coming to an end. If for no other reason then the effort of rolling back every affected package every time is too high. I'm not sure what the alternative would be, reviewing every adoption request seems like too much effort and wouldn't necessarily even help every time.
But isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package, etc? (Unless you are running them somewhere without internet access or without access to anything you don’t mind being public?)
Maybe it’s not the case for aur, but the others could theoretically be improved with better permissions, sandboxing, etc. I guess browser extensions basically have those options, even if no “normal” users use them.
Unfortunately 99.99% of people can’t or don’t have the time to review everything. :-(
I guess distro packages where there are trusted maintainers, or places like the iOS App Store where there are both permissions and somewhat of a review process, are the safest.
Ultimately, the way we're doing permissions on the OS level is fundamentally broken on desktop OSes, and we're increasingly feeling the effects of that. Ideally everything should be sandboxed by default, and only given access to it's own files, instead of everything the user has.
But we're a long way away from that, and that's not something a single project could enforce.
Yes, and all of those have supply chain hacks in them, and have happened within the last year? In this specific case, it's a malicious npm package being installed with official npm tooling in the PKGBUILD.
The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing, they are very simple bash scripts. It'd be great if more people would donate resources to help verify and validate AUR scripts, but the AUR specifically exists for packages that the trusted users and devs of arch don't have time to personally maintain.
I don't really think this is a solution- the usual workflow for these attacks has been to hide your payload in some dependency. This one is somewhat unusual in that it's just a very lazy `npm install` in the pkgbuild. Pretty much every package repository even outside of AUR has this issue now, and it's not really viable to audit the entire dep chain by hand. Mind you, I don't have a solution either.
Having code reviewed the PKGBUILD doesn't mean the upstream software is safe to use, having reviewed the upstream software and it's dependency tree doesn't mean the PKGBUILD is safe to use.
Believing that even a small fraction of users actually do this is deeply detached from reality.
It is not that hard with small amount of pkgbuilds:
find ~/.cache/yay -maxdepth 1 -type d
/home/virt/.cache/yay
/home/virt/.cache/yay/google-chrome
/home/virt/.cache/yay/ngrok
/home/virt/.cache/yay/rancher-k3d-bin
/home/virt/.cache/yay/simplescreenrecorder
/home/virt/.cache/yay/ttf-comfortaa
/home/virt/.cache/yay/cursor-bin
/home/virt/.cache/yay/yay
/home/virt/.cache/yay/volta-binAs far as Arch goes, I wonder if Arch-based CachyOS is a factor as it's seen the high performance desktop linux.
My favorite Aur helper (pikaur) also asked you to check the PKGBUILD on every install or update, back when I used Arch.
Even the most primitive LLM review workflow would have caught this compromise.
Adding or modifying any invocation to a PKGBUILD that may download something from the network and execute it (whether using npm, pip, curll|bash, or whatever else) -> automatically quarantine the PR and flag for 2 human reviews required. Same for anything that looks like obfuscation. Same for anything that adds dependencies on the wrong language ecosystem (like new use of javascript ecosystem tools in a c++ based package).
I have no idea why they don't do this already.
Maybe doing automated LLM reviews would help, but this is a large infrastructure investment. And it's not clear that it helps at all, after all models are quite vulnerable to prompt-injection type attacks.
On balance, the false sense of security that the automated check would provide might actually be detrimental.
Eg. change AUR API URL slightly so yay/yaourt users need to look up what is going on. New API should have infrastructure for informing users and making sure they've read the message before proceeding. Especially when they're not even sure that all malware was found.
Also there should be database of revoked/compromised AUR commits and there should be mechanism to warn user if they had it installed.
Other than this — I don't know how many there are affected people in total, but AUR team probably has an exact number. I am also sure, they're doing their best to handle it accordingly to the impact.
> New API should have infrastructure for informing users and making sure they've read the message before proceeding.
How would that even work? AUR packages are just git repos, everything that AUR helpers are doing or not doing is not under the control of the arch maintainers.
Are you seriously asking how would sharing short text notes over internet work?
If you need to be 100% git-centric, you can have git repo for messages. Client will then remember last commit displayed to user and refuse to continue unless latest message was displayed.
BTW some AUR clients displayed ArchLinux RSS feed before... Too sad the issue is not even mentioned in the RSS feed...
There is a shortage however of people skilled enough to implement them (with available time to do so).
What we also don't have a shortage of is angry people in comment sections.
There are AUR helpers, but these are completely unaffiliated with arch and the people running the AUR. The canonical, recommended way of installing arch packages is cloning a git repo, reading through the sources and then building it with makepkg. There is no client there that could show the user anything.
for example when you rename gitlab repository, or push to new branch, gitlab injects custom text that you can see. Eg. with new URL or where you can create merge request on web, etc...
Maybe they'd be an option, but then the whole "making sure they've read the message before proceeding" part goes out the window.
If you don't want to list all known effected packages, at least recommend the official position that anyone using a AUR package should be reading every file of every package they use.
I know its all volunteer work and extremely not fun at the moment, but it feels weird to not even have some sticky-no-reply on the AUR sub forum with a list of compromised packages. You have to instead try and scrape them up from around threads like here or reddit.
https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...
It's honestly more trouble than it's worth to get your package deleted, instead leaving orphaning as the more optimal way to relinquish control. This should be the opposite in my opinion, or at the very least the users should be made very aware that an orphaning has occurred. Perhaps that burden is more on the AUR helper like paru and yay (who I would encourage to make such a change).
I think we are well past (1) but (2) could be mitigated by tighter controls on AUR accounts and potentially additional safeguards from AUR helpers. Maybe show a big scary warning if the package has changed owners recently. I know there will still be people that will "y" their way forward but it's better than nothing.
Or just avoid AUR helpers altogether and inspect/build the packages you need yourself from their PKGBUILDs directly.
You know that thing where if you make a security review feature obnoxious, after some time people will just accept everything without even looking? Yeah...
Right now, this is the most up to date, consolidated utility to check for infection:
https://github.com/lenucksi/aur-malware-check
Also, the aur-request mailing lists has many delete/orhan requests coming through to undo the malicous commits:
https://lists.archlinux.org/archives/list/aur-requests@lists...
Really conveys that sense of urgency + the stakes tied to a major malware attack like that.
There's a lot of voodoo in that script, i can't easily tell it's safe by reading the code.
I'd expect some reaction/solution from official Arch developers...
All of the packages I have triaged involved the atomic-lockfile npm package, so this is something you could try:
npm cache ls | grep atomic-lockfile
https://cscs.pastes.sh/aurvulntest20260611.sh
Not my script. It's easy to read/parse. Never pipe a script directly to bash.
comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/3f768dce7331618310f016d975bf8547/raw/beef579f8a8efeed6ccf60788e5b768775550095/packages | sort)
Always check PKGBUILD and sources, AUR is not to be trusted for the most part. I'm actually more surprised that such compromise hasn't happened earlier.
it happens all the time
Just not always on this scale and doesn't always end up on HN.
Similar to how you don't see every npm supply chain attack or malicious github action or similar on HN.
In general you _have to_ manually review every PKGBUILD update by hand (by diff). Everything else is neglect IMHO. Luckily for most packages this is reasonably doable, IFF you trust the upstream sources they fetch from. (As in: Most packages are a small amount of glue between pacman and a upstream source.)
As consequence AUR packages with AUR dependencies are in general "uh..., lets not do it" cases for me, as on one hand the review overhead can be a pain and on the other hand it's easy to make a mistake overlooking a change in AUR dependencies.
Still the policy which allows relatively easy adoption of orphaned packages is IMHO a problem. A adoption should be treated as a new package which just happen to have the same name. (It can be fine to not have that if arch maintainers "bless" the adoption, but IMHO that would only matter for a view very widely used packages which are candidates to be included in the official repo but aren't for e.g. license reasons.)
This is like the 3rd or 4th time. It's been ongoing and persistent for the last 2 years with frequent AUR downtime as a result.
The AUR should be deprecated in its current state, simply can't be trusted and is a blemish on an otherwise great distro.
After correcting, for me, it flagged "jd-gui", but I had actually installed "jd-gui-bin" about two hours before the compromise. As far as I can tell, I was lucky that I felt lazy that night and went for the -bin package instead of waiting for the source to be compiled.
It is an officially maintained package and I always assumed these were built on a dedicated build server instead of some a random volunteer/home computer. Don't know if Arch still builds the same way but this event scared me enough to switch distros.
There's warnings in place if a .so dependency is detected, but it's up to the maintainer to notice and act on it.
For safety/security concerns, Arch Linux has been one of the driving forces in the reproducible builds project, and for large parts of the operating system it's possible to independently verify that those binaries have in fact been built from source code. It's auditing story for official packages is stronger than that of NixOS (and on par with Debian):
https://reproducible.archlinux.org/
All of this is entirely unrelated to the AUR incident however.
I'd really prefer to see a model where a 'community' repository contains user submitted packages which have at least one Trusted User review the package before it's merged in. This doesn't just prevent malware, but also common mistakes in general.
A large number of "an Arch Linux update broke my system" is very likely due to incorrect AUR use that AUR helpers don't handle for you. There's an elaborate writeup here from just 2 months ago: https://lists.archlinux.org/archives/list/arch-dev-public@li...
https://hn.algolia.com/?dateRange=last24h&page=0&prefix=fals...
https://news.ycombinator.com/item?id=17501379 https://news.ycombinator.com/item?id=44607740
https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
I toyed with the idea that someone should write a binary that simply emails, or alert you when it's been run... as a canary... and call that `npm`.
At this point, not renaming the npm binary is a big risk.
Internet archive URL: https://web.archive.org/web/20260611213640/https://aur.archl...
I have 1,135 packages installed. Only 3 top level packages are from the AUR and 2 of those 3 are from the same author, they just happened to split their packages into a client / server architecture.
[0] ...which is -IIRC- Gentoo's term for a user-provided and entirely-unvetted collection of packages...
The headline got my heart going pretty good this morning.
You can check the build and install date with `pacman -Qi <package>`.
I run Arch Linux in a container (within Fedora Silverblue), but my plan for the future:
- consider switching away from Arch Linux for my dev container, with great sadness. A rolling distro is a terrible idea in the current security climate. I loved using Arch for my dev container exactly because of AUR.
- switch to Fedora Stable, perhaps the previous release which still gets security fixes but no other updates. I am still on Fedora 43, I guess I have no rush to update to 44. - be even lazier in updating my workstation. I used to update daily when I was running Arch, then I moved to weekly last year when I got stuck with slow internet, now consider updating monthly or more (of course, unless there are critical security bugs)
- Flatpak and Flathub terrify me, it's only a matter of time until malware appears. I have had automatic upgrades disabled for a while.
- for the love of God don't touch anything that uses npm
Previously: https://news.ycombinator.com/item?id=48458931
I thought Flathub has a review and approval process. Does it fall short in some fundamental way?
Any review process is more than the AUR and NPM are doing.
If your manifest is covertly injecting malware into the build it could be easily missed. Consider some of the manifests are simply downloading deb packages and unzipping them.
This is a bit of an odd response. Arch very explicitly separates the AUR from everything else and doesn't make it easy to work with, because its security model has always been fundamentally broken and requires you to do your own vetting. It exists to facilitate sharing of package recipes between untrusted users. You should treat it like a pastebin.
I disagree that "These packages are provided as-is. No work has been done to determine their safety or fitness for purpose. Use at your own risk!" is a "fundamentally broken" security model. It's one that places the burden of verification and validation on the system administrator and -in the case of the AUR- fully informs them of this fact. Treating system operators like the adults that they are isn't "fundamentally broken", but it is _much_ more work for that operator than if they relied exclusively on distro-vetted packages.
I do agree that it'd be fucking silly of OP to switch away from Arch because some of the packages in the collection of packages that are explicitly provided as "as-is and unvetted" got some malware in them.
PKGBUILDs are easily readable/reviewable and rarely go beyond a single page. Just take a moment and be responsible and review before running executable files you download from the net. Common sense stuff. That's always been the trade-off and it hasn't really changed much in last 20 years (even though every few years everyone seems to freak out over it).
The problem is more that the Arch value proposition kinda presupposes the sort of user that's going to "feel superior" about having it installed[0]. It leads to people that have no business installing Arch Linux (as it doesn't match their usecase) installing Arch Linux because it makes them feel cool.
I don't have a good answer for this, besides making it more apparent what people should expect from having Arch installed. My recommendation usually goes something like this:
* Do you want to have the latest version of all software, regardless of the question if it's well-tested beforehand?
* Do you want to have all software distributed in an as-close-to-upstream approach as possible? Be aware that "upstream" configuration can sometimes significantly differ from defaults most people expect. (Sometimes there's reasons for this, sometimes upstream are a bunch of obstinate jerks.)
* Are you comfortable with a terminal?
* Are you comfortable with needing to suddenly learn how to troubleshoot a broken system after a routine update?
Only if the answer to all of those is "yes", then Arch is suitable for you.
And finally, more specific to servers, where the answer should be "no" if you want to use arch:
* Do you have the expectation to never have to touch the OS after it's been configured correctly besides routine maintenance (ie. installing security updates) and maybe a big update twice a year?
I used to use Arch, before realizing that my system was gradually morphing into a bespoke mess that didn't really serve my needs and that while doing something very specific was possible, I also had to configure a bunch of mundane stuff you aren't normally required to think about - there's never a "just install, activate and adjust as needed" with Arch. All I actually wanted was a distro with more recent software than "3 years old" (Debian/Ubuntu's sluggish package inclusion is not really useful for desktops).
So I looked around and realized Fedora worked better for me: professional, clean, recent software (every 9 months updates, feature freezes are smart enough to account for ie. New Python releases) and not prone to sudden surprises.
[0]: https://wiki.archlinux.org/title/Arch_Linux is a good example of it.
Arch still hits the sweet spot for me -- unobtrusive, close to upstream, and well-documented enough to keep full control over your own system. Both for the times when you want to go with the most default path and for the cases when you want to deviate and go play in the weeds.
Now, someone could argue that the Spotify app isn't important, but there's a reason it has 268 votes. A better solution would be having packages like spotify in their own repo, and a separate, you-better-verify repo for the rest.
[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=spoti...
> Now, someone could argue that the Spotify app isn't important, but there's a reason it has 268 votes. A better solution would be having packages like spotify in their own repo, and a separate, you-better-verify repo for the rest.
I mean yeah, but everything is trade off of volunteer + user attention. There is no trusted user™ who uses spotify, so it's not in official packages. So you as user need to maintain it yourself or rely on AUR and verify.
>The result is a rather long list of ~408 packages all doing npm install atomic-lockfile something something
[0] https://lists.archlinux.org/archives/list/aur-general@lists....
And yes, this is an AUR issue, but npm being used to host and dissiminate malware is also [a chronic] one, even if separate.
The fundamental problem is having something that has very loose oversight and next to no controls. That may have worked in the past, but in the day and age of constant supply chain attacks, it's a major liability.