undefined | Better HN

0 pointsamiga3866mo ago0 comments

An example: Java Maven artifacts typically name the exact version of their dependencies. They rarely write "1.2.3 or any newer version in the 1.2.x series", as is the de-facto standard in NPM dependencies. Therefore, it's up to each dependency-user to validate newer versions of dependencies before publishing a new version of their own package. Lots of manual attention needed, so a slower pace of releases. This is a good thing!

Another example: all Debian packages are published to unstable, but cannot enter testing for at least 2-10 days, and also have to meet a slew of conditions, including that they can be and are built for all supported architectures, and that they don't cause themselves or anything else to become uninstallable. This allows for the most egregious bugs to be spotted before anyone not directly developing Debian starts using it.

0 comments

jml786mo ago

You forgot to mention it is also tied to provable namespaces. People keep saying that NPM is just the biggest target...

Hate to break it to you but from targeting enterprises, java maven artifacts would be a MASSIVE target. It is just harder to compromise because NPM is such shit.

redwall_hp6mo ago

Maven Central verifies the domain used for the package namespace, too. You need to create a DNS TXT entry with a key.

This adds a bit more overhead to typo squatting, and a paper trail, since a domain registrar can have identity/billing information subpoenaed. Versus changing a config file and running a publish command...

panny6mo ago

Maven central also requires package signing. You're not stealing my signing key. It's on a yubikey. Game over, you can't publish malware in my name using my key.

philipwhiuk6mo ago

> An example: Java Maven artifacts typically name the exact version of their dependencies. They rarely write "1.2.3 or any newer version in the 1.2.x series"

You can definitely do this.

To be honest, you just end up with the same thing via dependabot/renovate.

amiga386OP6mo ago

Yes, that's why I said "typically" and "rarely".

You can specify a dependency version range in Maven artifacts. But the Maven community culture and default tooling behaviour is to specify exact versions.

You can specify an exact dependency version in npm packages. But the npm community culture and default tooling behaviour is to specify version ranges.

Even if a maintainer uses a bot to bump dependency versions, most typically they will test if their package works before publishing an updated version, and also because this release work is manual (even if the bot helps out), it takes some time after the dependency is released for upstream consumers of it to endorse and use it. Therefore, nobody consuming foo 1.0.4 will use dependency bar 2.3.5 until foo 1.0.5 is released... whereas an npm foo 1.0.4 with bar dependency "^2.3.0" will give its users bar 2.3.6 from the very moment bar 2.3.6 is released, even without a foo 1.0.5 release.

j / k navigate · click thread line to collapse