218
Sees the title: It's npm isn't it?
clicks: Yeah, It's npm...
this post was submitted on 16 May 2026
218 points (96.6% liked)
Programming
27009 readers
232 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 3 years ago
MODERATORS
I would have guessed snap, but maybe that's just me
My thought process exactly.
Two phrases come to mind
- Play shitty games. Win shitty prizes
- Vote for a clown. Elect a circus.
Personal experience. JavaScript is garbage on its own. Npm is a Russian nesting doll of untenable garbage built on it.
There's definitely a problem with the "JavaScript culture". The whole "we're going to make everything as easy as possible" approach has some definite negatives, but when you raise them you get accused of gate-keeping.
But like - yeah, we should be gate-keeping. At least for published and shared code. Having high standards for software development is a good thing. When you don't you get npm.
Python suffers from this a bit as well - but not as bad as the JavaScript ecosystem where relying on a third-party package that does some trivial function is seen as "normal".
Amazing that moderate-effort generated images look this good now, and yet i immediately twigged that it's not a real photo.
Lo and behold i look closer and indeed the text is garbled nonsense.
Are they intentionally priming the models to have this weird aura of surreality? Or is it just something inherent to AI-generated images that's somehow really difficult to avoid?
Entire generations are subconsciously being trained to detect AI, better than another AI can.
While this is true, there's still a very consciously visible "style" to these images. It's too obvious for me to call it subconscious.
Like the weird focus, the text on the whiteboard looking like a digital font.. The individual things that are weird are quite easy to point out.
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.
2FA should probably be enforced for the process of publishing packages
The most successful recent attacks haven’t relied on stolen user credentials, so this point is kind of moot. API tokens are way easier to obtain and use. Typo squatting and phishing are more effective, and attackers generally don’t need to bypass 2FA.
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.
Linux users who routinely download and compile src packages is a minuscule attack vector. Most users download binaries, so this point isn’t true either.
And look, I agree that MFA should be mandatory everywhere, and sandboxing is great, but the truth is that the JS ecosystem is chock full of lazy and sloppy devs. That’s just how it has been for the longest time, and no amount of security measures targeting them specifically is going to fix the current state of affairs, because as soon as one is implemented, someone will find it too cumbersome and will find a way to override it. The whole ecosystem needs adult supervision.
But honestly, I believe that JS in the backend has been a massive mistake and we all should abandon it as soon as possible. There are plenty of better languages and ecosystems out there, no need to keep self inflicting this kind of pain.
Api tokens are also a stolen credential. They are getting stolen via things like unsandboxed malicious packages that search for them.
That is TeamPCP's main modus operandi, they have an infostealer that tries to nab whatever credentials it can find, and then uses those to spread more.
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.
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.
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
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.
I'm sure there are advatages to making web apps over regular software for OS's and that supply attacks can happen anywhere.. but the idea this is unavoidable is insanity. Stop making reckless "modern" web apps.
Speaking of "modern web apps" does OpenSUSE still use Firefox as an installer? When I tried the new major version on release I watched a browser unexpectedly open and slowly load a page. Coming from a snappy dedicated installer of prior versions, this made me question if I had downloaded malware.
wait what? when was firefox used as an installer?
Leap 16, and yeah the web app OS installer is called Agama.
RIP YaST
It doesn't seem like a crazy idea to me to have some "second tier" of packages that undergo a higher level of scrutiny and have to pass that before they are released in that tier.
Maybe an arbitrary set of security endorsements would be more flexible.
That permits retaining a low bar for just making the stuff initially-accessible in packaged format, but also helps developers in raising the floor.
Like, okay. Say I have something like:
$ cat .config/npmrc
required_security_endorsements=["npm_auto_audit", "maintainer_id_validated", "european_cybersecurity_competence_center_tier_1", "nsa_tier_1"]
$
An attempt to install a release of a package without those endorsements fails.
That's going to always create pressure to get something a security endorsement so that it can be used by people who only permit packages with some given security endorsement, but it lets parties start running security endorsement projects to improve the situation without excluding any existing projects from pushing stuff to npm.
EDIT: Also, I've not done much node.js development, but assuming that the dependencies in a package manifest default to the newest version unless specific frozen versions are mandated, a la PyPI, it might reasonably be able to fall back to versions with the required security level automatically, if they're available. If the dependency format permits specifying optional dependencies, a particular dependency could be automatically excluded to conform to the security endorsement requirements list.
A much simpler solution is to add all of the basic stuff into the base library so that people don't need to include 50 packages to do stupidly simple stuff, but Javascript has shown very little desire to harden itself or grow. They have relied on community contribution to fill their missing design holes and now it is biting them in the butt.
Many things are working in vanilla, just packages are created for fun? Like isEven, isThrteen and so on.
Devs can add these to .npmrc. And in top tier professional workplaces we do things like this. Sure devs can override, but it’s explicit at that point.
ignore-scripts=true
min-release-age=14
In enterprises all packages are copied, scanned, and hosted internally with requests for packages from public locations blocked.
Great ideas. Who's going to pay for it? Are opensource devs supposed to wrote the code, maintain it, and audit other people's code too?
to have some "second tier" of packages that undergo a higher level of scrutiny and have to pass that before they are released in that tier.
The reverse: to have a trusted category, where they know the dev.
Fuck NPM and all the stupid morons that perpetuate it.
I knew I was making the right choice whenever I avoided that dumb shit like the plague.
Do you not use a package manager for JS/TS development?
Nope. "JS development" for me has always been limited to what it was meant for: webpages.