Live data from Hacker News

Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

phoronix.com

151–160 of 227 posts

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#151
post #129

Has anyone from the AUR team (such as that is) published a retrospective yet? This was some impressively fast firefighting but in all honesty, it seems like some changes are needed, either in AUR policies or in the wrappers. I should be able to set a minimum package age just like I can with pnpm. Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign…

> I should be able to set a minimum package age just like I can with pnpm.

I recently worked up a patch [1] for pakku [2], after being inspired by pnpm.

[1] https://github.com/gavinhungry/patches/blob/main/pakku/pakku...

[2] https://github.com/zqqw/pakku

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#152
post #130
post #13

Earlier quoted context omitted.

`yay` (one such wrapper) shows me the PKGBUILD diff on every update. The first time I install something I verify the URL, and check any install script etc. seems sensible; the vast majority of subsequent updates are changes to just version number & checksum. A typosquat attack would be very obvious. (It's a bit vulnerable to it on first install, but so is 'just navigate to the project website [and click download]'.)

Does it also show each patch involved?

It shows the overall diff since last update, not patch-wise. But it does show any extra patch file, install script, etc. – not just the PKGBUILD – if that's what you meant.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#154

I’m not on Arch Linux, but I am on NodeJS a lot, which frequently suffers from similar types of attacks. Who is doing package management right these days? Who is doing it securely?

Linux distributions are. They all have maintainers who vet packages and take responsibility for them. Arch Linux does too. The inherent untrustworthiness of the AUR was always made explicit by the Arch Wiki and the culture surrounding it, unlike programming language package managers like npm and pip.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#155

This is something that worries me with a distribution like Alpine Linux. It is hard to avoid a package like chromium [0] or firefox which are in the "community" repo. Now have fun check it at every update, this is not practically feasible. For the web browser one can say we should use Flatpak anyway but there are a lot of other apps like sway from the community repo that cannot be flatpaked. - [0] https://pkgs.alpine…

But the community repo in Alpine is vetted and reviewed unlike AUR, which is a wild west.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#156

Earlier quoted context omitted.

> That's a semantic detail based on the choice of build from source over binary distribution. It's not, AUR is more like GitHub, anyone can upload content there, not like a proper repository where things are reviewed, verified and cared for. You're complaining about "curl https://random-website.com | bash" being "a semantic detail" while it's a major difference in how much trust you can put into it. If you don't trus…

GitHub doesn't allow me to put up my old repos for adoption by any old rando, or to allow randos to request to take over my repos if I don't respond for 2 weeks. GitHub also actually protects against repojacking and tombstones username/reponame combinations (that exceed a certain minimum popularity) and never lets anyone ever use them again. The utility of AUR is also really based around being able to reuse the same…

> GitHub doesn't allow me to put up my old repos for adoption by any old rando, or to allow randos to request to take over my repos if I don't respond for 2 weeks.

Changing your username would let anyone reuse the old username for whatever they want. Probably still today there are bots squatting any renamed accounts. Also, you bet Microsoft would hand over your GitHub username if it was reported by someone who holds a registered trademark in the US over that username, regardless of impact.

> The utility of AUR is also really based around being able to reuse the same repo without having to re-vet every single time.

I don't think they promise that anywhere, nor should you have that expectation. That would be like since you got legit copy from random-website.com/bin.exe today, you'd get that tomorrow too, clearly not true unless you know the owner of the domain or otherwise trust it.

> go has a software package manager that heavily uses GH for distribution, and is arguably more VCS decentralized, but isn't vulnerable to this kind of attack

Unless Golang suddenly have peer-reviewed packages, Golang has exactly the same problem as AUR in that anyone can create packages, and it's up to users to decide what to trust or not. Fair that the whole "orphaned packages" thing doesn't exists in Golang, but I think Arch probably favors stability more than people expect/think, that's why people can continue to maintain packages even though original maintainer disappears. Ultimately it's a trade-off, I don't think there is some absolute truth what is correct or incorrect.

Regardless of who maintains the package, if you use AUR as intended, it seems you'll avoid most security issues. It's when your expectations aren't aligned with what AUR actually promise, that people start getting hacked.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#157

So from a quick read, it seems it installed "atomic-lockfile", "js-digest" or "lockfile-js" from npm. A list of affected packages is here [1]. Didn't find any quick info on how to check a system, so I ran the following command to find foreign packages and some date related infos: > pacman -Qmi Check the output against the list of affected packages. Then, you can also grep for those files in various locations: > grep…

Here is how I did it :

Get a list of installed packages originating from AUR using 'yay' :

  yay -Qam > packages_aur.last
Get list from https://md.archlinux.org/s/SxbqukK6IA# :

  curl https://md.archlinux.org/s/SxbqukK6IA/download > compromised.txt
then :

  grep -wFf compromised.txt packages_aur.last
should spit out the packages that are in both files, hence were compromised at some point, I guess.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#158
post #96

Earlier quoted context omitted.

"Review" them how? Read every single line of code before installing something? If it's a binary package, how do you do that? Make reproducible builds for everything you install? Move to from source distro? Putting this on users is not a tenable solution. There's room for common sense, but blaming the users for this is ridiculous

This is like saying a user who clone a random git repo is not to blame and git-scm should do more to prevent cloning of malicious repos. If it is not official, it is your job to review, if you dont like it, use iOS instead of Arch Linux. If you crash your car, you are liable for the accident. If you aren't ready for that, take the bus. More power = more responsibility

> If you crash your car, you are liable for the accident.

Because I didn’t go through all the blueprints and find the flaw that led to the crash. This is a dumb argument. It’s also the one the AUR appears to be making.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#159
post #129

Has anyone from the AUR team (such as that is) published a retrospective yet? This was some impressively fast firefighting but in all honesty, it seems like some changes are needed, either in AUR policies or in the wrappers. I should be able to set a minimum package age just like I can with pnpm. Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign…

Better would be to namespace AUR packages. That way, ownership is not lost and we don't need orphaning at all.

Re: Arch Linux Now Believes Malware Incident Under Control: More Than 1,500 Packages

#160

Earlier quoted context omitted.

GitHub doesn't allow me to put up my old repos for adoption by any old rando, or to allow randos to request to take over my repos if I don't respond for 2 weeks. GitHub also actually protects against repojacking and tombstones username/reponame combinations (that exceed a certain minimum popularity) and never lets anyone ever use them again. The utility of AUR is also really based around being able to reuse the same…

> GitHub doesn't allow me to put up my old repos for adoption by any old rando, or to allow randos to request to take over my repos if I don't respond for 2 weeks. Changing your username would let anyone reuse the old username for whatever they want. Probably still today there are bots squatting any renamed accounts. Also, you bet Microsoft would hand over your GitHub username if it was reported by someone who holds…

I don't know how it works these days, but a few years ago GitHub was happy to give away usernames from users who haven't touched their accounts in a long time to anyone who asked. Several people I know got vanity usernames that way. All you had (have?) to do is drop an email to GitHub's support.
Post reply on HN