Live data from Hacker News

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

phoronix.com

21–30 of 227 posts

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

#21

As always a fair reminder to not install random 3rd party packages/libraries/applications without reviewing them, especially when there is zero vetting. Luckily this was constrained to AUR, which basically is a free-for-all package repository, with users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories. `rua` and other similar CLIs make it rea…

>`rua` and other similar CLIs make it really easy to review the packages before installing them from AUR too, and if you are doing banking on the same computer, you really have no excuse not to review the software you depend on.

What review should users do?

It appears that, in some cases, these were adding npm as a dependency and installing atomic-lockfile, and in others, these were adding bun and installing js-digest. This was a mass attack against mostly low-use/orphaned/etc packages where maintainership was taken over or a different user uploaded a new version (itself a very simple, low-notice, low-oversight process), and many of the packages clearly had no connection to Node.js at all, so a user who knew enough about each package, and knew what npm was, might notice the oddity in the package, if they reviewed every line of the PKGBUILD, then reviewed the install scripts.

But legitimate AUR packages for packages connected to Node.js also use npm, for example, and at times, use npm install. A user would have to be familiar enough with Archlinux's build system to understand the difference between each part (eg, build() vs install scripts). They'd have to review every PKGBUILD, every install script, and every patch of every AUR package they install. For packages that actually do use npm/bun, they'd have to be familiar enough to know what uses were legitimate and what uses were not, and might have to be up to date on compromised dependencies. And this is still considering a mass attack that was not particularly hidden. Attacks could be made much harder to find.

Asking a user to safely review an AUR package essentially seems like it is asking them to fully understand not just the build process, and programming language, of the upstream package, but also all details of Archlinux's build system. They need to learn how to do this with, as far as I can tell, no real guidance: AUR itself, and the wiki's page on it, just warn that users should carefully review the PKGBUILD and install scripts, without giving any substantial guidance on what to look for or how to review anything. The warnings feel much more like liability-reduction than an attempt to be helpful.

At that point, what is AUR actually offering that installing the upstream package isn't? It feels like the suggested 'safe' way of using AUR would make it just as much work for the user, and require just as much knowledge, as either installing the upstream directly, or even making a package for it.

There is perhaps some room for LLM analysis here: Opus 4.8, Kimi latest, and even Qwen3.6 27B quickly catch at least the current round of malicious packages in my tests. But a motivated attacker could make that more difficult, or dangerous. And a user could also just have those models install the upstream package, with less risk. If they want to use pacman for management, they could likely even have those LLMs generate a package, with less risk.

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

#22
post #7

As I undertood it this was mostly orphaned packages?

Not even "packages" in the distro sense. You can't use software installed with Arch to install this stuff via any path that isn't isomorphic to rebuilding the package yourself.

This was the AUR repository, which is the community-maintained soup of non-distro packages. They're packaged using the same tools and technology, with the intent that they can be easily validated and promoted to core stuff in the future. But they aren't really "Arch Linux". You need to deliberately enable and install tools to pull stuff from it.

Think of this as Steam or Chrome. You can install those on Arch, and people do, but if Chrome extensions or Steam games suffer an incident like this you don't blame the distro.

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

#23
post #18

Earlier quoted context omitted.

For me, this tradeoff isn’t worth it. I didn’t switch to Linux so that I can waste time going to websites and clicking “download” to update my programs like a Windows user. The pacman wrappers you mention are crazy, though.

I get it, but you only need to do that for the odd cases of packages not present in the official repo (not that common at all for me at least). Also if the software is downloaded in the form of a git repo, you only needed to checkout the new tag and rebuild, don't need your browser at all.

I think the existence of the AUR puts less pressure on the official repository to have all popular software.

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

#24
post #5

I cringed hard when some people started to make pacman wrappers that could install from AUR directly. I've installed stuff from the aur before but most of the times I prefer to skip the middleman and just navigate to the project website. A premade pkgbuild is not convenient enough to take the risk of typoquatting or the tactical npm or pip dependency.

This sounds like your update process is quite involved then. Or do you just not do it?

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

#27

As always a fair reminder to not install random 3rd party packages/libraries/applications without reviewing them, especially when there is zero vetting. Luckily this was constrained to AUR, which basically is a free-for-all package repository, with users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories. `rua` and other similar CLIs make it rea…

> users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories. I think this stance should be re-evaluated. Arch Linux developers are doing a fantastic job and I am personally thankful to them - this is not in any way critical of them. And while I don't see an easy solution here, I just feel that the time of "warning users" is long gone with how muc…

Idk. Arch does have official repositories that are actively maintained and vetted. AUR is for the vast amounts of random software that isn’t popular or important enough to be officially maintained.

I’m not sure how to find a balance. One reason to use Arch is to always have the latest software, especially if you’re gaming. (Need to run very recent kernels, GPU drivers, and DEs to support new graphics cards.) So that’s very different from other stable LTS distros which carefully pick the package updates they incorporate.

Anyways, I do agree package cooldowns and such make a lot of sense. Package managers should be pulling out the stops on all the free controls they can implement. I can understand why anything requiring compute or maintainer time is a non-starter. (Sidebar: I don’t feel the same way about npm. Microsoft can afford to run malware scanners and analysis tools on npm packages.)

https://wiki.archlinux.org/title/Official_repositories

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

#29
post #21

As always a fair reminder to not install random 3rd party packages/libraries/applications without reviewing them, especially when there is zero vetting. Luckily this was constrained to AUR, which basically is a free-for-all package repository, with users being warned multiple times that it's vital to review anything before you install it, compared to the official repositories. `rua` and other similar CLIs make it rea…

>`rua` and other similar CLIs make it really easy to review the packages before installing them from AUR too, and if you are doing banking on the same computer, you really have no excuse not to review the software you depend on. What review should users do? It appears that, in some cases, these were adding npm as a dependency and installing atomic-lockfile, and in others, these were adding bun and installing js-diges…

> At that point, what is AUR actually offering that installing the upstream package isn't?

It produces package files that pacman can use. Sure, you can curl|sh or whatever, but that's a good way to litter stuff all over that you can't track or uninstall cleanly.

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

#30

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?

Arch is fine if you do not use AUR. If you use AUR check everything.

Most distros are too. All the big distros have pretty good track records.

Post reply on HN