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

201–210 of 234 posts

Re: AUR packages compromised with Infostealer and Rootkit

#201

Post by seba_dos1 »

Tharre wrote: post #153
tetromino_ wrote: post #136

Earlier quoted context omitted.

> Any and all modifications to PKGBUILDs may download something and execute it A normal PKGBUILD should not download anything programmatically. It should rely on the package manager to download the files listed in the PKGBUILD's source array. If a PKGBUILD is running a command to download something not listed in source, that's a sign that something nefarious could be happening, and such a PKGBUILD absolutely requires…

> If a PKGBUILD is running a command to download something not listed in source, that's a sign that something nefarious could be happening, and such a PKGBUILD absolutely requires careful human review. First, although I don't disagree with that being how it should work, in a world where everyone relies on npm, cargo, etc. to handle dependencies this scenario is not realistic. Second and more importantly, it doesn't r…

> in a world where everyone relies on npm, cargo, etc.

Only certain niches do. No Debian package can connect to the Internet while being built, and the Debian Archive contains vast amounts of software that makes a computer useful.

Reliance on npm, cargo, etc. makes it harder to package certain things, but in general they're the exception rather than the rule.

Re: AUR packages compromised with Infostealer and Rootkit

#202

Post by Ferret7446 »

j-bos wrote: post #144
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…

Yeah, I don't even use the AUR. If I need something, I'll just build it myself. Convenience is dangerous.

> If I need something, I'll just build it myself

That's basically what the AUR is.

Re: AUR packages compromised with Infostealer and Rootkit

#203

Post by Ferret7446 »

hypfer wrote: post #122
kpcyrd wrote: post #87

Earlier quoted context omitted.

There's no shortage in ideas of how to make the AUR easier to moderate. A "quarantine button", an invite system, a request system for adoption similiar to how orphan requests work, code review attestations similiar to cargo-crev, pacing controls similiar to those in discourse. There is a shortage however of people skilled enough to implement them (with available time to do so). What we also don't have a shortage of i…

People have all right to be angry if basic responsible adult things like "quarantine the server spreading large amounts of malware" do not happen within the reasonable timespan that passed. Not even a news. A hint. Nothing. Radio silence. ___ There is a house. It is currently on fire (since over 24h). So far, people have talked about how, conceptually, house fires are bad. You can still enter the house just fine. Peo…

Why are you still misunderstanding when other replies already explained?

AUR has always been AT YOUR OWN RISK.

To use your analogy, the house is an underwater cave with a big scary sign warning you that you will die, you go in without training, and blame the cave for not being safe.

Re: AUR packages compromised with Infostealer and Rootkit

#204

Post by Hackbraten »

simoncion wrote: post #54
jorams wrote: post #44

Earlier quoted context omitted.

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

> ... because its security model has always been fundamentally broken... I disagree that "These packages are provided as-is. No work has been done to determine their safety or fitness for purpose. Use at your own risk!" is a "fundamentally broken" security model. It's one that places the burden of verification and validation on the system administrator and -in the case of the AUR- fully informs them of this fact. Tre…

I agree. If you use the AUR, you're essentially no longer running Arch Linux but your own private fork of Arch Linux.

Re: AUR packages compromised with Infostealer and Rootkit

#205

Post by Ferret7446 »

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.

SLSA adoption

Re: AUR packages compromised with Infostealer and Rootkit

#206

Post by hypfer »

Ferret7446 wrote: post #203
hypfer wrote: post #122

Earlier quoted context omitted.

People have all right to be angry if basic responsible adult things like "quarantine the server spreading large amounts of malware" do not happen within the reasonable timespan that passed. Not even a news. A hint. Nothing. Radio silence. ___ There is a house. It is currently on fire (since over 24h). So far, people have talked about how, conceptually, house fires are bad. You can still enter the house just fine. Peo…

Why are you still misunderstanding when other replies already explained? AUR has always been AT YOUR OWN RISK. To use your analogy, the house is an underwater cave with a big scary sign warning you that you will die, you go in without training, and blame the cave for not being safe.

My man, this thread has already achieved the intended outcome (or has just temporally coexisted).

There is no need to argue anymore. Enjoy your computers.

Re: AUR packages compromised with Infostealer and Rootkit

#207

Post by Hackbraten »

rossvor wrote: post #94
bachmeier wrote: post #81

Earlier quoted context omitted.

I think the issue with AUR is that you get your foot in the door with packages like spotify[1]. It does its magic to allow you to install a .deb package on your distro. I don't know how else to install the Spotify desktop app without AUR. But once you're willing to do that, why not go a little further and trust other packages? Now, someone could argue that the Spotify app isn't important, but there's a reason it has…

I don't have it installed, so I can't comment if it requires constant babysitting, but looks pretty okay to me -- it has no AUR-only dependencies (++), one extra shell script (--), popular (++ given enough eyeballs...). Should be fairly easy to review, anything fishy should be fairly visible in git diff. If I needed it I would be using this PKGBUILD. It's a net gain that it exists there, someone else done most of the…

> There is no trusted user™ who uses spotify, so it's not in official packages

That's not the reason why Spotify is not on extra.

Spotify is not on extra because it's not FOSS.

Re: AUR packages compromised with Infostealer and Rootkit

#208

Post by tim-projects »

Here is the direction I'm heading in:

- I run arch on the host. The host runs qemu.

- Qemu VM 1 runs my work machine.

- Qemu VM 2 runs my financial stuff.

It took me about 2 days of work to figure out how to virtualized my machine and maybe months of tinkering after that to get it right.

I'm trying to separate general work use and payments to entirely separate security models.

I've also begun moving all dev work to cheap vps's that I run online with AI agents.

Re: AUR packages compromised with Infostealer and Rootkit

#209

Post by cyanydeez »

codemac wrote: post #116
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…

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

if someone setup a properly vetted LLM farm to donate local LLM resources, id give it ~8 hours a day on whatever model i have loaded.

Re: AUR packages compromised with Infostealer and Rootkit

#210

Post by m463 »

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…

I should mention - if you follow the instructions on the arch wiki to use the AUR the instructions tell you not to trust things.

That is the burden of arch linux, and the beauty. you have to go through it and you have to learn.

Now just hoping that people are reading (and learning from) the arch wiki going forward, not just agents. sigh.

hmm... I guess people insulate themselves after a while with stuff like yay

Post reply on HN