Live data from Hacker News

AUR packages compromised with Infostealer and Rootkit

discourse.ifin.network

31–40 of 234 posts

Re: AUR packages compromised with Infostealer and Rootkit

#31

Obviously 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…

There was never an era in which #2 was a reasonable policy.

Re: AUR packages compromised with Infostealer and Rootkit

#32
post #15

AUR doesn't guarantee security, its upto the user to use AUR & verify before installing anything, its very evident why arch is not used in enterprise solutions.

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

Re: AUR packages compromised with Infostealer and Rootkit

#33
post #16

AUR doesn't guarantee security, its upto the user to use AUR & verify before installing anything, its very evident why arch is not used in enterprise solutions.

It's not the AUR. It's the rolling release cycle, and probably even more importantly, lack of support options.

Agree

Re: AUR packages compromised with Infostealer and Rootkit

#36

Obviously 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…

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”

Re: AUR packages compromised with Infostealer and Rootkit

#37
post #4

This is especially gnarly as more people have been picking up arch distros as of late (like CachyOS).

On the bright side you can get quite far without the AUR.

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.

Re: AUR packages compromised with Infostealer and Rootkit

#38

How a person 'adopts' 408 packages and controls their build scripts?

Orphaned packages, so other people are able to file requests and take over them. That's how AUR works — it's community-driven [0].

[0]: https://wiki.archlinux.org/title/Arch_User_Repository

Re: AUR packages compromised with Infostealer and Rootkit

#39
post #27
post #16

Earlier quoted context omitted.

It's not the AUR. It's the rolling release cycle, and probably even more importantly, lack of support options.

The AUR has absolutely nothing to do with the rolling release cycle

yes & comment didn't mention that both are dependent, fooqux is correct.

Re: AUR packages compromised with Infostealer and Rootkit

#40
post #7

Be aware of false positives! I found I had two of these packages installed, clang19 and compiler-rt19, but due to my recent laziness in updating my system, mine were still the versions from July 2025 from the official repos before they had relegated them to AUR. You can check the build and install date with `pacman -Qi `. I run Arch Linux in a container (within Fedora Silverblue), but my plan for the future: - consid…

> Flatpak and Flathub terrify me 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.

Flathub only reviews the manifest.

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.

Post reply on HN