Live data from Hacker News

AUR packages compromised with Infostealer and Rootkit

discourse.ifin.network

221–230 of 234 posts

Re: AUR packages compromised with Infostealer and Rootkit

#221

Earlier quoted context omitted.

>You have to review the source of every PKGBUILD from the AUR you install, full stop Believing that even a small fraction of users actually do this is deeply detached from reality.

"Review every PKGBUILD" is as realistic as expecting the EULA to be completely read and understood (including the forced arbitration clause) before clicking "I Agree". It also ignores the poor souls using AUR helpers that automatically download and build packages from AUR as they were designed to do for the convenience of Arch/AUR users. AUR isn't just some download site. It has been actively marketed by Arch for at…

> That creates the expectation, rightly or not, that the Arch User Repository provides some degree of protections for Arch Users against the build sources hosted there being compromised.

The main page of the AUR website says, in bold, "DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk."

Re: AUR packages compromised with Infostealer and Rootkit

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

Arch shipped a broken fontconfig package 10 days ago. The broken version is still the one offered.

Re: AUR packages compromised with Infostealer and Rootkit

#224
post #182

Earlier quoted context omitted.

To be honest, it took me way too long to figure the Arch etc crowd are hobbyists who enjoy having something which always 'needs maintenance' over the weekend. (And maybe they don't want to admit they are hobbyists because what they are doing seems Very Important.) Sorta like 'car guys' who recommend some old thing you can wrench on.

For what it is worth, while I'm sure it is right on target for some, I think that's incorrect model of a mean arch user. Updates are once a month thing for me (and the maintenance for that rarely exceeds 10m if that). I barely do any distro level tinkering, after all, I need to spare some time to improve my emacs config ;). Basically, my model of a mean arch user would be closer to a DIYer -- likes to follow clear ma…

Hey, your response improves my opinion of 'car guys'. Because the analogy is thin and they are looking directly at what is coming out of the 'sausage machine'. And if the result is good, they could sell the machine for profits! (Unlike computer nerds.)

I'm sticking with "hobbyists/dabblers" here, because almost nobody runs Arch in real production scenarios. Its just a fun high-touch thing people can enjoy fucking around with. Nothing wrong with that.

(That is why someone could trivially trojan hundreds of packages and it's NBD. Because "Nobody Cares." Wipe it and start over, funguy.)

Re: AUR packages compromised with Infostealer and Rootkit

#225
post #213

Earlier quoted context omitted.

> If I need something, I'll just build it myself That's basically what the AUR is.

Except for the "you"rself part.

In that the AUR involves running a build command and scripts that you didn't put together.

Re: AUR packages compromised with Infostealer and Rootkit

#226
post #131

Earlier quoted context omitted.

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.

> 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. How many AUR packages are you assuming people are installing?

Could be one or one thousand. Frankly, the exact number doesn't matter.

I'm assuming people are using the AUR to install programs that are sufficiently complex and the idea one can trivially audit a complex program and all of its dependencies is foolish. The foolishness of that expectation scales with the number of complex programs installed.

The idea that users should "just check the source code every single time" has never been, nor will it ever be, a reasonable solution to supply chain attacks.

Re: AUR packages compromised with Infostealer and Rootkit

#227
I think that AUR is a not a very good idea.

It's essentially uncensored platform. I think they can moderate it, but obviously only for high-visibility cases.

Anyone can create package with any name, potentially impersonating any other project.

And that's all on archlinux.org domain, which inherently adds some trust to the whole concept. Trust that is unfounded.

If someone wants to distribute PKGBUILD, they should put it to Github or any other git hosting.

Re: AUR packages compromised with Infostealer and Rootkit

#228
post #226

Earlier quoted context omitted.

> 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. How many AUR packages are you assuming people are installing?

Could be one or one thousand. Frankly, the exact number doesn't matter. I'm assuming people are using the AUR to install programs that are sufficiently complex and the idea one can trivially audit a complex program and all of its dependencies is foolish. The foolishness of that expectation scales with the number of complex programs installed. The idea that users should "just check the source code every single time" h…

> Could be one or one thousand. Frankly, the exact number doesn't matter.

It does. Manually checking a couple of AUR packages is easy. Installing a thousand AUR packages is not something anyone should be doing.

> I'm assuming people are using the AUR to install programs that are sufficiently complex and the idea one can trivially audit a complex program and all of its dependencies is foolish. The foolishness of that expectation scales with the number of complex programs installed.

Nobody is asking them to do that. The premise is that the `PKGBUILD` and auxillary files provided by the AUR should be checked.

> The idea that users should "just check the source code every single time" has never been, nor will it ever be, a reasonable solution to supply chain attacks.

Again, nobody is asking anyone to do this.

Re: AUR packages compromised with Infostealer and Rootkit

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

Arch itself is just a collection of user-produced PKGBUILDs. It's provided without warranty (like any GPL code).

The difference is that Arch got a trusted reputation throughout the years, while in AUR even the packages that also have a reputation can suddenly change their owner - which produced the current issue.

Post reply on HN