Hacker News Reader

Comment by bitmasher9 | Hacker News Reader

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?

The AUR is user supported and thus malware sneaks into packages all the time, although admittedly not to this scale. Still, it's pointedly not secure and has always had "here be dragons" signs plastered all around it.

That’s not so much an example of who is using best practices, as it is an example of who is using worst practices.

> Who is doing package management right these days? Who is doing it securely?

QBASIC. When you need a package you type it in from a magazine. Virtually anything you could ever need is only 1-12 weeks away.

QuickBasic, the commercial version of QBASIC, also supported BI files. These could be used to bundle shared code for things like high-precision timers, interrupt usage, etc.

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.

Having trusted community members vet packages is a good system, but how much does it really scale?

1. The whole point of the AUR is that the demand for packages outstrips the volunteer effort to provide secure packages.

2. There are about a dozen major package systems for Linux, with a lot of duplicated effort in packaging the same software for slightly different systems in slightly different formats.

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.

> Who is doing package management right these days? Who is doing it securely?

The malware was limited to package sources that I understand to be disabled by default, if you're using Arch Linux. These package sources carry clear warnings that the packages they provide are controlled by third-parties and entirely unvetted by the distro maintainers. [0][1]

If your assertion is that any package management system that permits the installation of packages that aren't vetted by the maintainers of the -er- OS that uses that package management system is "not doing it securely", then the only one that's even vaguely "doing it securely" is Apple's iOS.

I'm of the opinion that permitting users of a general-purpose computer to install arbitrary software is a good thing, and is pretty much the entire point of a general-purpose computer. I'd call computers that make that effectively impossible "appliances". There's very definitely a place for appliances, [2] but seeking to turn every computer into an appliance is massively destructive.

[0] <https://aur.archlinux.org/>

[1] <https://wiki.archlinux.org/title/Arch_User_Repository>

[2] Reliable computers that you never have to think about because they simply never fail to perform the useful tasks they were designed to do are great.

It's a lost battle.

Everything will need to be run in a VM separated from your main desktop which should have your data and a minimal amount of apps.

Qubes OS was ahead of it's time.

I think something about the node ecosystem makes it particularly vulnerable. Maybe it's the insane "dry" ethos. Or something else.

Nothing I have ever used has a comparable dependency tree nightmare.

I think most ecosystems have more batteries included than node.

There are definitely LTS distros where the official packages are not updated ASAP. Npm lets package authors publish new versions to all users immediately. Anything that doesn’t allow that is better. Some distros only incorporate patch/security updates for example.

AUR is worse, in that there may not be official authors and you can take over releases of a package. Like, you’ll have random users publishing the release for some application that doesn’t have their own Arch release. And if that user disappears, someone else may take it over

Min Release Age of 7-30 days covers the majority of potential issues with 0 effort.

All major Node package managers should support it by now.

Prom was the best IIRC, yarn second, but even npm is catching up

We’re using an internal package repository that acts as a gateway to the public package repositories, except it can have custom rules such as “min release age 30 days”, and can also give logs about which projects have actually downloaded a specific version.

It’s so much overhead and auditing to enforce compliance across the thousands of node microservices though.

That’s a great idea. Maybe use Claude Code with some owasp knowledge to sweep through them and see if there’s anything obvious?

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.

Reply on news.ycombinator.com