[flagged]
AUR packages compromised with Infostealer and Rootkit
61–70 of 234 posts
Re: AUR packages compromised with Infostealer and Rootkit
#62Earlier quoted context omitted.
There was never an era in which #2 was a reasonable policy.
The canonical answer to any concerns with the AUR is always “just read the PKGBUILDs bro”
For every single update, for all your AUR packages, all the time.
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...
Re: AUR packages compromised with Infostealer and Rootkit
#63Re: AUR packages compromised with Infostealer and Rootkit
#64There are some AUR hooks that can help. I use https://github.com/Sohimaster/traur which also has scans for orphan package takeover patterns.
Re: AUR packages compromised with Infostealer and Rootkit
#65Earlier quoted context omitted.
Arch is not used in enterprise solutions because of the AUR? Can't you just not use it?
AUR is choice, rolling release is the reason
No, it's not. If Debian had a community-maintained repo of additional packages, the same thing could happen there.
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.
Re: AUR packages compromised with Infostealer and Rootkit
#66Wow, this is effectively the end of the AUR model. There's been a malicious package or two before, but an attack this widespread shows things are fundamentally broken. Guess I'll be switching to a new OS this weekend across multiple machines.
> Guess I'll be switching to a new OS this weekend across multiple machines. 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 pa…
Tbh Arch itself is the most explicit about this compared to the derivatives. Manjaro etc allow installing AUR stuff directly from their main package manager
Re: AUR packages compromised with Infostealer and Rootkit
#67[dead]
Re: AUR packages compromised with Infostealer and Rootkit
#68People 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 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.
Re: AUR packages compromised with Infostealer and Rootkit
#69So what's a solution to this? Install packages like this in Docker containers without network access? I don't think we should assume it's limited to AUR. Every software source should be considered suspect in 2026, particularly with the adoption of vibe coding, and closed software is a bigger mess than open source because it's a black box.
Yes, "untrusted" "app stores" should be sandboxed (including AUR, FlatPak, ...) Probably with a VM, at least as a default/option.
Re: AUR packages compromised with Infostealer and Rootkit
#70Earlier quoted context omitted.
Arch is not used in enterprise solutions because of the AUR? Can't you just not use it?
AUR is choice, rolling release is the reason
Rolling release has nothing to do with this. It could just as well be a PPA in ubuntu or any deb repo for debian or similar.