Also....

Maven doesn't have "preinstall, install, post install", or " build.rs" for rust, executing arbitrary code during the installation.

The code that's executing with Maven is in your pom.xml, not some hidden code from a transient dependency.

That alone is a major design flaw in both npm and cargo.

Java is boring, because it works. People don't like boring stuff. It's more exciting to play the Russian roulette on each install!

As a heavy user of Java I can assure you that Java is very very far from boring, especially when building it with maven or gradle. There are millions ways something can screw up the build. Rust (and Go too) in comparison is much more boring actually - it maybe I was just lucky, but the majority of stuff just builds with zero issues.

Especially the number of times I had to clean all the caches in order for maven and gradle to build the project is just far too high for me. It shouldn’t ever be needed if an ecosystem is meant to be considered boring. I feel like Java doesn’t build when I look at it wrong.

> I feel like Java doesn’t build when I look at it wrong.

Hah, too true! I guess it is boring in the fact that it is not as... move fast and break things... as NPM. But Java build systems are still certainly fun and challenging in their own ways.

Yep, sounds boring!

How does Maven handle JNI? Is it also a build system for C/C++, or do packages with native bindings require manual build steps?

I googled a bit and found this snippet:

            <plugin>
                <artifactId>exec-maven-plugin</artifactId>
                <version>3.5.1</version>
                <groupId>org.codehaus.mojo</groupId>
                <executions>
                    <execution>
                        <id>Generate-shared-lib</id>
                        <phase>package</phase>
                        <goals>
                            <goal>exec</goal>
                        </goals>
                        <configuration>
                            <executable>bash</executable>
                            <arguments>
                                <argument>generate-lib.sh</argument>
                            </arguments>
                            <environmentVariables>
                                <JAVA_HOME>${env.JAVA_HOME}</JAVA_HOME>
                            </environmentVariables>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

At least with certain plug-ins Maven will execute arbitrary commands at build time. And if you need that to build native bindings it feels like a big hole. Granted, most projects don't need JNI, I guess.

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.

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.

> 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.

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.

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.

> 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.

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.

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.

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.

$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.

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!

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?

> 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.

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.

And domains can change hands legitimately.

Or be forgotten to renewed, lost and, depending on registrar, overtaken.