'No way to prevent this,' says only package manager where this regularly happens (opens in new tab)

The idea that 7 days is overkill is crazy to me. Unless you need a specific new feature, you should usually be fine with a dependency version that was released months ago when starting a new project. Ditto for doing regular dep upgrades.

The only issue I see is responding to vulnerabilities, where you want to upgrade immediately. But I think in that case it's fine to require the developer to be explicit in the new version they want.

Seems like you dropped something:

> Disclaimer: I maintain depsguard

yes, props to pnpm for adding 1 day cooldown by default in v11.

Release escrow.

Teams should be able to say "at least N developers have to agree to a release before it happens." This should be a policy they can control and lock down with a non developer account.

This is like buying something from the grocery store and then waiting a week to eat it in case the FDA put out a warning about it.

It is 100% up to the package manager's steward to control how ownership of packages and namespaces are granted.

Maven Central exists for decades the amount of incidents of people stealing namespaces is minimal.

One can't simply publish a package under the groupId "com.ycombinator" without having some way to verify that they own the domain ycombinator.com. Then, once a package is published, it is 100% immutable, even if it has malicious code in it. Certainly, that library is flagged everywhere as vulnerable.

It baffles me that NPM for so long couldn't replicate the same guardrails as Maven Central.

Part of the point the article makes is that most other popular languages have a comprehensive standard library. JS has an astonishingly small on. Rather than have one vetted set of libraries that ship with the language, applications either need to roll it themselves or pull from a 3rd party package repository. We've drilled NIH into people, so they tend to reach for packages. That's not necessarily a bad thing, but it often means they're pulling in more code than they need. The JS ecosystem has also favored smaller modules, so you need many of them. And everyone builds on top of that, leading to massive growth in dependency graphs. It's a huge surface area for things to go wrong, intentionally or not.

With many other languages, you have a lot of functionality out of the box. Certainly, there have been bugs and security issues, but they're a drop in the bucket compared to what you see in the JS ecosystem. With other languages, you have a much smaller external dependency graph and the core functionality is coming from a trusted 3rd party.

> It seems like it might just be that Python/npm are juicier targets?

Attackers go where the victims are. Frontend is a monoculture with the vast majority using NPM; backend, less so. This isn't an excuse for NPM, but another strike against it.

You could also argue that the attacks make a deeper point about frontend vs backend devs, but I won't go there.

To be honest Rust has the exact same supply chain attack pattern - it's just newer and more maintained at the moment. Give it a decade.

Last I checked npm had 2FA for publishing, but cargo didn't. I don't think cargo is any better than npm, just not that of an attractive target.

I suppose that go's go:generate workflow can also be abused to land a worm like the ones spreading via npm, as you can build programs that just scrape the whole hard drive for git projects and patch the go.mod dependencies there, and you could also just write this in go as a toolchain script, for example.

NPM's achilles is the pre/postinstall step which can run arbitrary commands and shell scripts without the user having any way to intervene.

Dependencies must be run in isolated chroot sandboxes or better, inside containers. That would be the only way to mitigate this problem, as the filesystem of the operating system must be separated from the filesystem of the development workflow.

On top of that most host based firewalls are per-binary instead of per-cmdline. That leads to the warnings and rules relying on that e.g. "python" or "nodejs" getting network access allowlisted, instead of say "nodejs myworm.js". So firewalls in general are pretty useless against this type of malware.

none. they just have smaller target populations.

Generally, other package managers aren't great either. Notably, crates.io / cargo has some of the same people behind it as NPM and the verbiage of their excuses is oddly similar.

Something fascinating about the design and architecture of programming languages and their surrounding ecosystems is the enormous leverage that they provide to the "core team":

For every 1 core language developer[1]...

... there may be 1,000 popular package developers...

... for which there may be 1,000,000 developers writing software...

... for over 1,000,000,000 users.

This means that for every corner that is cut at the top of that pyramid, the harms are massively magnified at the lower tiers. A security vulnerability in a "top one thousand" package like log4j can cause billions of dollars in economic damage, man-centuries of remediation effort, etc.

However, bizarrely, the funding at the top two levels is essentially a pittance! Most such projects are charities, begging for spare change with hat in hand on a street corner. Some of the most used libraries are often volunteer efforts! cough-OpenSSL-cough.

The result is that the people most empowered to fix the issues are the least funded to do so.

This is why NPM, Crates.io, etc... flatly refuse to do even the most basic security checks like adding namespaces and verifying the identity of major publishers like Google, Microsoft, and the like.

That's a non-zero amount of effort, and no matter how trivial to implement technically and now cheap to police, it would likely blow their tiny budget of unreliable donations.

The exceptions to this rule are package-managers with robust financial backing, such as NuGet, which gets reliable funding from Microsoft and supports their internal (for-profit!) workflows almost as much as it does external "free" users.

"Free and open" is wonderful and all, but you get what you pay for.

[1] Most of us can name them off the top of our heads: Guido van Rossum, Larry Wall, Kerningham & Richie, etc.

Just dont use npm. Use a package manager which doesn't execute postinstall by default. The switch is incredibly simple.

What do you mean by safe config? If you're trying to mandate a cooldown period or a whitelist/blacklist of packages, the correct approach is to configure a company-controlled registry that pulls from the upstream npm registry while enforcing your desired policies.

We wish them well.

install scripts are a distraction, just like package signatures are a distraction. adding/removing either feature has no significant impact on the wormability of this package ecosystem. installed npm code is run, with nearly zero exceptions.

This doesn't really fix the issue though because package code is also executed at build time and during testing. Just maybe restricts the scope a little bit.

...and only if you invoke it with --dangerously-run-postinstall-scripts; otherwise it will report an error if a postinstall script is found.

This is definitely going to affect any packages that need to link to native code and/or compile shims, but these are very few.

That, and package owners updating stuff that needs no updating just to look not stale/unupdated. I can use lisp packages without changes for 15 years fine, but a js one is unmaintained! oh no! Even though it was done 15 years ago, so they add nothing, sometimes a breaking change, to up a version on npm and github and look maintained. And then everything will update.

Both are parodies of The Onion's long-running series of articles.[0]

[0]: https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

The form of wording goes back at least to 2014 in The Onion

https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

The NIH mentality in the ecosystem would result in a JavaScript pgp library which itself would be an npm package and subject to supply chain attacks. lol.

Would that help? Most of these recent attacks, the attackers have gained access to the system that builds the packages. So it would have just signed the malicious build the same.

Its a reference to an Onion article about gun violence in the US

XZ attacker spent half a year earning trust, doing real maintenance.

Different order of magnitude effort spent during XZ attack.

Security doesn't exist in absolute. It's about relative effort. Exploiting Debian's package management requires quite a bit of effort, NPM, while being funded by Microsoft, only need to have a token stolen. And postinstall scripts were decried as a security risk for a long time

UV adoption is happening, though. NPM is still the only name in town.

Apparently it does now: https://packaging.python.org/en/latest/specifications/pylock...

https://pip.pypa.io/en/stable/cli/pip_lock/

But who cares about pip, uv is here.

I don't know about snails, but everything I'm in contact with has moved over to uv, and I can't imagine I'm the only one.

Same vibe: https://www.youtube.com/watch?v=lOTyUfOHgas

the onion article is still up could link that

I don't like vanilla JS though. I like easier-to-read abstracted JS.

subtree is better for this case, you want to encourage actual reading before running. reading won't catch everything but it catches a lot, and the burden isn't as high as people always complain about before they try it.