200
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 16 May 2026
200 points (97.2% liked)
Programming
26970 readers
520 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
Doesn't lots of package managers have the exact same problems?
It "regularly happens" in NPM because it has one of the biggest attack surfaces. You think hackers are spending a meaningful amount of time taking over abandoned Lua projects?
Not linux distro package managers.
Things like the AUR in Arch Linux are also susceptible to this. About a year ago there were malicious versions of popular browsers e.g. firefox-patch-bin or librewolf-fix-bin in the AUR. As others have said, NPM has a huge attack surface because it is practically used by everyone which is probably why it is targeted a lot more.
Because distro packages rely on a small group of trusted maintainers, while anyone can publish anything to the NPM registry.
Also, distro packages are usually full fledged applications or libraries, which require a certain number of developers upstream to maintain them. There are thousands of NPM packages out there that are essentially walking corpses waiting to be infected.
I disagree. There are many process failures and areas where security can be improved, independent of trusting a distro maintainer or developers.
For example, 2FA should probably be enforced for the process of publishing packages. It does appear to be enforced for new packages but older packages still have legacy settings. Github now forces 2fa for basically everything, and they applied that even to existing organizations and repos. There is no real reason that NPM (owned by Github) isn't able to do the same.
Or another example, is sandboxed builds. Many of these packages, like NPM and Rust packages, have build time scripts, which are executed unsandboxed at compile/install time of these programs. That is how these NPM worms have been so pervasive. You don't have to actually run the javascript package for it to do bad things, just merely installing it.
On the other hand, the build systems that distro's use, often involve sandboxing the builds to limit the attack surfaces (including limiting network access). Although, Linux distros usually rip out build scripts and build systems in order to replace them with their own, but this also further limits the code you have to audit.
Even better is to sandbox the program itself to further limit harm but that's not done on Linux distros and is somewhat outside the scope of this discussion.
If you are an NPM developer, I recommend Deno, with it's built in, on by default sandboxing... that people like to disable. But it's there and is better than giving random NPM package #245 access to your home directory. You could also use podman or docker but yeah.
One of these days I should really look at the specific differences that means Linux packages rarely experience this while npm it happens seemingly once a month.
One of the biggest difference is package signing, which is often multi party where multiple developers review changes and coordinate uploads.
There are others, like how Debian and Red Hat essentially maintain forks of software which they only apply cherry picked security updates to. This blocked the XZ utils backdoor, for example. Debian Unstable, Arch, and other distros which shipped newer versions of software got the backdoor. But not Debian Stable and Red Hat.
I wrote a long post here, in which I go more in depth: https://programming.dev/post/48171483/23081855
Typically people only have trustworthy repositories configured. The amount of people with access to deploy on those is low. Less keys, less chance of someone stealing one.
Plus, let's be honest, people deploying linux packages are probably much more security-conscious than people deploying a random but useful javascript lib on npm.
Chain of trust for one.
Yes, a lot of programming language package managers do have similar problems as npm.
I dunno. I use Debian, Arch, and Guix on top mostly for development, and these fit my needs very well.