Earlier quoted context omitted.
I do it too, but I can see why this can be a problem for users. There should be an "official" scan for potentially malicious changes. I use a third party AUR scanner to help me with this.
What third party scanner do you use?
AUR packages compromised with Infostealer and Rootkit
181–190 of 234 posts
Re: AUR packages compromised with Infostealer and Rootkit
#182Earlier quoted context omitted.
You’re not wrong, but then we ought to pump the brakes in telling everyone and their mother to hop onto arch based distros that make installing AUR packages seem as safe as any other action (via Shelly on cachyos for example)
To be fair, the advice very rarely is for people to jump onto Arch based distros. 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…
To be honest, it took me way too long to figure the Arch etc crowd are hobbyists who enjoy having something which always 'needs maintenance' over the weekend. (And maybe they don't want to admit they are hobbyists because what they are doing seems Very Important.)
Sorta like 'car guys' who recommend some old thing you can wrench on.
Re: AUR packages compromised with Infostealer and Rootkit
#183People need to get into their heads that the AUR is just a collection of user-produced PKGBUILDs. 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 abo…
> You have to review the source of every PKGBUILD from the AUR you install, full stop 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…
> 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.
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.
Re: AUR packages compromised with Infostealer and Rootkit
#184People need to get into their heads that the AUR is just a collection of user-produced PKGBUILDs. 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 abo…
>You have to review the source of every PKGBUILD from the AUR you install, full stop Believing that even a small fraction of users actually do this is deeply detached from reality.
And most people don't ever check their car oil.
The 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.
Re: AUR packages compromised with Infostealer and Rootkit
#185This campaign is still ongoing. I just got an email that one of my old packages (which hasn't worked for years and was orphaned for a while) was adopted and immediately a malicious commit was pushed. They seem to be using bun instead of npm now, so any npm-based workaround likely isn't effective. https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...
I'm wondering at this point if the idea of adopting orphaned packages is broken and should be removed. 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?
Absolutely! Supply chain attacks are always going to be a problem, but just letting someone take over a package because it hasn’t been touched in a while seems like a really poor policy.
If you want to change it, fork it!
Re: AUR packages compromised with Infostealer and Rootkit
#1867+ hours into this and still no mention on archlinux.org webpage nor on aur.archlinux.org. Why??? AUR should have been blocked until user takes action to prove he knows about this. 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…
Now acknowledged: https://archlinux.org/news/active-aur-malicious-packages-inc...
Re: AUR packages compromised with Infostealer and Rootkit
#1877+ hours into this and still no mention on archlinux.org webpage nor on aur.archlinux.org. Why??? AUR should have been blocked until user takes action to prove he knows about this. 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…
[deleted]
Re: AUR packages compromised with Infostealer and Rootkit
#188Obviously installing anything from AUR must be done cautiously and there have always been sketchy (as in improperly built/packaged) packages in the past but seeing actively malicious injections is concerning. I think there are two main problems with AUR: 1. it is a remnant of a slightly more egalitarian era in the open source history when you could generally trust 3rd party code and 2. orphaned packages can be adopte…
> Or just avoid AUR helpers altogether and inspect/build the packages you need yourself from their PKGBUILDs directly.
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.
Re: AUR packages compromised with Infostealer and Rootkit
#189Here's an easy script to scan for compromised packages: https://cscs.pastes.sh/aurvulntest20260611.sh Not my script. It's easy to read/parse. Never pipe a script directly to bash.
A quicker alternative: comm -1 -2 It's never a bad time to learn about comm(1).
Or the more powerful join(1) which can compare individual columns.
Re: AUR packages compromised with Infostealer and Rootkit
#1907+ hours into this and still no mention on archlinux.org webpage nor on aur.archlinux.org. Why??? AUR should have been blocked until user takes action to prove he knows about this. 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…
For good or for bad, this warning is ALWAYS present for AUR.
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...)