Has anyone from the AUR team (such as that is) published a retrospective yet? This was some impressively fast firefighting but in all honesty, it seems like some changes are needed, either in AUR policies or in the wrappers.
I should be able to set a minimum package age just like I can with pnpm.
Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign of attack.
Someone or something should vuln-scan these packages as they're published, as a number of companies do for NPM now. That would likely have found these pretty quickly.
Most of these are not changes to be made by the AUR maintainers, but rather by packaging helpers and 3rd parties.
mkayokaytoday at 1:51 PM
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"
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.
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.
anthonjtoday at 12:46 PM
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.
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?
landdatetoday at 2:01 PM
> 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.
28304283409234today at 2:04 PM
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'?
1vuio0pswjnm7today at 3:56 PM
What perecentage of Arch users compile the kernel and userland software from source
What Linux distribution^1 has the highest percentage of users who compile from source
Is it Gentoo
1. Besides Linux from Scratch
smetanniktoday at 4:20 PM
I might be wrong, but this situation seems like a signal of desktop Linux adoption growth
robby_w_gtoday at 1:12 PM
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.
sunshine-otoday at 2:15 PM
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.
As I undertood it this was mostly orphaned packages?
shevy-javatoday at 2:09 PM
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).
Simulacratoday at 3:18 PM
This is my fear with Linux and privacy - malware that leaks private data while using ie Tor, or other "anonymous" programs.