How does that protect against credential theft? MFA required to sign published releases?

That is another important layer. Maven Central is not immune to credential theft. If a publisher token is stolen, an attacker may still be able to publish a malicious new version until the token is revoked or the account is suspended after reporting the problem to Sonatype.

But in the Maven/Gradle ecosystem, most projects pin exact dependency versions. Support for version ranges and dynamic versions exist, but they are generally avoided because they hurt reproducible builds. That means a malicious new release does not automatically flow into most consumers’ builds just because it was published.

I'd go as far to say that NPM should:

1. Enforce scope (namespace) requirement, and require external verification (reverse DNS for example).

2. Disable version range support out of the box. User must --enable this setting from the command line at all times.

3. Remove support for install scripts completely. If someone wants to publish a ready-to-run software, there are plenty of other mechanisms.

▲

TiddoLangerak 25 days ago | parent | next [-]

You're missing the biggest root cause though, and that significantly hinders how well this translates between languages: the Java community has settled on fewer but large monolithic dependencies, whereas the JavaScript community has settled on many but small composable dependencies (for good historical reasons, but that's a topic in and off itself).

This directly influences how well e.g. version pinning works. In the Java world, package versions are _relatively_ independent from eachother and have few transitive dependencies, and as such version conflicts are relatively rare. This means you can get away with full pinning of all dependencies, with the occasional manual override of a conflicting transitive dependency.

This doesn't work in JavaScript. The dependency ecosystem is massively intertwined, if every library would specify exact versions you'd end up with literally hundreds of conflicts to resolve. That's not feasible. As a result, they've chosen the middle ground of using lock files in addition to version ranges.

This also hurts the effectiveness of verified namespaces: when packages come from hundreds of different sources, you're not going to notice 1 or 2 sketchy ones in there.

Other consequences of the big monolithic packages in Java are that updates tend to be less frequent, and more often from large reputable venders. Both of these help to reduce the problem too.

While the JavaScript toolchain can definitely learn a lot from the Java toolchains, the problems it needs to solve are not the same, and thus solutions don't translate 1-1.

At least I hope that they'll get rid of install scripts, that's such a low hanging fruit that really should've be done a decade ago.

	▲	dns_snek 25 days ago \| parent [-]
		> At least I hope that they'll get rid of install scripts, that's such a low hanging fruit that really should've be done a decade ago. How will that help? It's just going to break things that legitimately require them. Instead of being infected upon running "npm install", you'll just get infected upon running "npm run" instead. The former is slightly more reliable but fixing that is just kicking the can down the road. Maybe we'll have a few days before the payloads get rewritten.

▲

nayroclade 25 days ago | parent | prev | next [-]

Dependency versions are also locked for npm projects via package-lock.json, and this has been the default behaviour for years. The version ranges specified in package.json don't mean you just pick up the latest whenever you run npm install. Unless you delete package-lock.json or run "npm update", you and everyone else gets the exact same dependency tree each time. So it is just as reproducible as a Maven build in that sense.

	▲	panzi 24 days ago \| parent [-]
		Plus the lock file doesn't just contain the exact versions, it contains hashes. Making sure that you actually got the package in the exact same version.

▲

com2kid 25 days ago | parent | prev [-]

> Enforce scope (namespace) requirement, and require external verification (reverse DNS for example).

Who the heck says everyone who publishes a library has a domain? That seems absurd.

▲

brunoborges 25 days ago | parent | next [-]

Sonatype allows "io.github.<username>" as a valid groupId and has a process to verify ownership. I am sure other providers like GitLab can work on this.

▲

oarsinsync 25 days ago | parent | prev | next [-]

You can get subdomains for free from a number of places, some of which are more reliable than others.

This exists because domains (historically) used to be expensive by western standards. .com used to be $75/year back in the day.

▲

chadgpt3 25 days ago | parent | prev | next [-]

Why don't you? It costs around $20 per year. Every serious computer nerd should have one, and a web server with at least a basic homepage.

▲

whatevaa 25 days ago | parent [-]

$20 per year on US is not the same value across the world. Would you say $60 per year is ok too, if you adjusted for income? 100$?

Don't count other people money.

▲

lelanthran 25 days ago | parent [-]

The problem with this argument against, is that it reinforces the point it is arguing against: If a contributor cannot afford the $20/year to publish for a single 12-month period, then they are already a risk - someone could buy their account off them.

A small bar of $20/year is also enough to completely cut-down on contributors who sign up with the intention of publishing malicious packages: they have to pay $20/year for each malicious package they want to publish!

▲

com2kid 24 days ago | parent [-]

Why should someone need a credit card to contribute to open source? Why should they need to understand DNS?

Heck domain names are ephemeral, forget a deadline by a day and they are snatched up my squatters. They don't provide any extra guarantees. Do we really think a domain requirement is going to stop state level actors that are already stealing 2FA package publishing tokens from major software orgs?

▲

lelanthran 24 days ago | parent [-]

> Do we really think a domain requirement is going to stop state level actors that are already stealing 2FA package publishing tokens from major software orgs?

Is that your target? Because if so, then nothing will stop them.

	▲	com2kid 24 days ago \| parent [-]
		The most recent attacks have been incredibly sophisticated, executed against orgs that have taken all the right steps. Requiring domain name verification is not going to do anything when 2FA tokens are being stolen. What it will do is prevent students and people who want to stay anonymous from contributing to open source.

▲

radlad 25 days ago | parent | prev [-]

And domains can change hands legitimately.

	▲	whatevaa 25 days ago \| parent [-]
		Or be forgotten to renewed, lost and, depending on registrar, overtaken.