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

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

phoronix.com

Post reply on HN
Print view View original

221–227 of 227 posts

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

#221

Post by dualvariable »

tredre3 wrote: post #180
dualvariable wrote: post #178

Earlier quoted context omitted.

Only thing I can find on requesting to take over an inactive account is here: > We do not accept requests to release, transfer, or reclaim usernames on the basis that they appear inactive or unused. If the username you want has already been claimed, you will need to select a different available name unless you are submitting a trademark complaint as described below. https://docs.github.com/en/site-policy/other-site-p…

Github has changed their policy in 2022. Before that it was possible to contact support to reclaim any username provided that they had no meaningful public repos and they were inactive for a long time. It was at the staff's discretion, there wasn't an elaborate policy of what constitutes inactive, but I've successfully reclaimed a username inactive for 2 years myself. The old policy was: GitHub account names are prov…

> Github has changed their policy in 2022.

Which means that in the age of supply chain attacks, they patched the holes.

Which is exactly why this policy that AUR has is terrible in 2026.

The fact that GitHub didn't have that policy back in 2015 isn't the counterexample that the argumentative crowd here seems to think it is.

That is the GH policy right NOW, in the year of our Dog, 2026.

AUR is pretty grossly behind the curve, and I'll certainly accept that GH was arguably slow about it.

Defending AUR's policy on the basis of GH's policy being shitty until relatively recently isn't a good argument.

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

#222

Post by irundebian »

aftbit wrote: post #202
cookiengineer wrote: post #187

Earlier quoted context omitted.

> Someone or something should vuln-scan these packages as they're published, as a number of companies do for NPM now. That would likely have found these pretty quickly. No. It wouldn't have. That's the whole point of the miasma worm, because it changes too fast in its signatures and helper methods. The encrypted malware implant uses a changing AES-128-GCM key that's used to decrypt the payload, and that key is per-wh…

With this _actual_ attack, it would have been trivial to detect. The signature was: 1. Orphaned package adopted 2. Has post-install hook added 3. Which uses npm or bun Yes, you're right - detecting this could have led to a more sophisticated attack. Security is always a cat and mouse game. The purpose isn't to stop every attack - it's to raise the costs for attackers and the visibility for defenders. Any attacker who…

Security is not always a cat and mouse game.

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

#223

Post by landdate »

bitmasher9 wrote: post #209
landdate wrote: post #42

Earlier quoted context omitted.

Running external code will always be a risk. Even if it is not intended to be malicious it could still have issues that compromise security. Read the source. If you don't have the time then you shouldn't run the software.

By “external code” do you mean code that is not written by yourself or the organization you are working in? The Linux Kernel has 40 million lines of code, I don’t have the time to read that so I guess I better not use it.

And you and me would be better off for it. You can rely on such insanely complex technologies that have required millions of man hours to develop in which even the most knwoledgable will lack a complete understanding, or you can live within your station.

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

#224

Post by landdate »

NekkoDroid wrote: post #72
landdate wrote: post #36

> It was bad enough when finding out more than 400 AUR packages for Arch Linux users had been infected with malware but now that number has risen to around 900 a few hours ago and now in the end at more than 1,500 user-contributed packages.been infected with malware I never had a need for the AUR. If I want a package not in the official repository I build it myself or if it has a binary release I will download it. th…

> this way i don't have to use root when building `makepkg` will actively refuse to run if you are invoking it as root (unless you specifically invoke it with something like `env EUID=123 makepkg ...`). > and can have program installed locally just for a single user which is how it should be anyway for most desktop use cases. I do wish pacman would support a user level installations. It will refuse to install package…

Maybe I used imprecise wording. Not root, but must be part of sudoers. Or am I misunderstanding how the process works? Don'tWhenever I have installed a package from aur with yay it requires user being part of sudoers.

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

#225

Post by NekkoDroid »

landdate wrote: post #224
NekkoDroid wrote: post #72

Earlier quoted context omitted.

> this way i don't have to use root when building `makepkg` will actively refuse to run if you are invoking it as root (unless you specifically invoke it with something like `env EUID=123 makepkg ...`). > and can have program installed locally just for a single user which is how it should be anyway for most desktop use cases. I do wish pacman would support a user level installations. It will refuse to install package…

Maybe I used imprecise wording. Not root, but must be part of sudoers. Or am I misunderstanding how the process works? Don'tWhenever I have installed a package from aur with yay it requires user being part of sudoers.

Yea, but that is to install the package after it was built (or installing dependencies). The build itself is done unprivileged.

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

#226

Post by saghm »

bitmasher9 wrote: post #210
saghm wrote: post #38

Earlier quoted context omitted.

I think it's also a bit of a testing ground for the main repos as well. I maintained the `ruby-build` AUR package for a couple of years after the previous maintainer wanted to step down, but they eventually added it to the main repos and now it's maintained by one of the official people. (I don't recall ever having to do more than paste in the new release tag into the PKGBUILD each time and then generate the new .SRC…

I’ve seen automation scripts for this process of updating packages. Makes sense that the most popular AUR packages will be candidates for the main repo.

I only saw automation around this for the first time earlier this year when noticing that a package was multiple versions out of date and tracking it down to a bot (in the pre-LLM sense) on Gitlab for the package that gave a false negative on a version update due to the format of the upstream git tags changing (either they added a `v` to the beginning or removed it, I forget which). My takeaway from that experience is that while automation can be nice, I'm not convinced that the benefits outweigh the potential for bugs like that if it relies on invariants like git tags that are realistically not something that all upstream maintainers are going to be pedantic about keeping standardized.

I understand that having a relatively small number of people maintaining a large number of packages makes it burdensome to manually update everything, but on the other hand, nobody asked me before promoting the AUR package I maintained to the main repos, and I would have been happy to keep doing it indefinitely! I'm not a "official trusted contributor" by any means, but I also know that I would have kept doing what I already did for years in exactly the same way without any issues, so I can't help but feel a bit like like a known good with hypothetical risks was thrown away for something that will produce at best the same results with less severe but more concrete risks. I wish I had a solution for not getting stuck at that local optimum, but incidents like the one in the article will only make it more of an uphill battle.

(edit: to clarify, I'm not proposing that the package should have been left in the AUR, but that I wish there were a way for them to have just let me keep maintaining it as an "official" package. Maybe something like the kernel model where someone trusted could vet the PKGBUILD updates I do and decide whether to merge them or not rather than doing the same but with a bot, and then maybe not noticing that the bot is silently failing...)

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

#227

Post by Gormo »

naturalmovement wrote: post #146
Gormo wrote: post #132

Earlier quoted context omitted.

AUR isn't a package repo. It's a collection of user-contributed PKGBUILD scripts, to make building packages from upstream source distributions more convenient. It's not meant to be treated like an official repo of binary packages.

> AUR isn't a package repo. What does the 'R' in AUR stand for? Rutabaga?

"Welcome to our ool. Notice that there is no 'P' in it. Please keep it that way."
Post reply on HN