I'm not inherently against the idea of specifying a hash, it would protect against NPM hosting infrastructure being compromised, but again, that's not what we're seeing here
But if we both attempt to install 0x456def, it's clear that whoever has 0xabc123 is in trouble. This is especially important in cases where you might need a package while you're on a separate network partition than npm. Any peer can provide it and you know it hasn't been tampered with because if it had been it would have a different hash.
If this happens, then either the NPM registry has been compromised or my system's 'npm' program or your system's 'npm' program has been compromised.
If the discrepancy is due to one of us running a malicious 'npm', then that malicious 'npm' CLI program could've just not flagged the signature mismatch, so specifying a hash doesn't help us anything.
If both of us are using a non-compromised 'npm' program, and the NPM registry isn't compromised, then we will never be in a situation where my "fooapp version 7.8.9" and your "fooapp version 7.8.9" differs. If a malicious actor compromises an account with publish access for the fooapp package, then all the malicious actor can do is publish a new "fooapp version 7.8.10" that has malware. That's what has happened in every single one of these high profile NPM hacks. You can't retroactively change old versions of your own packages. So to protect against this kind of attack (which, again, means every single NPM hack to date), just not auto-upgrading between minor versions is enough.
To protect against a compromised NPM registry, I agree that we should have package checksums living in our git repositories. But NPM already has that: the package-lock.json contains checksums. I don't understand what it would give us to have that checksum in the package.json instead of the package-lock.json.
> I've audited fooapp==7.8.9 and I believe it is both functional and free of malware
You might act on that information by installing it and locking it to a hash. In this scenario we've missed an opportunity to compare hashes. Maybe you end up with a different one due to a problem with NPM or with one of our connections to it (it's a high value target, so CA's behaving badly isn't out of the question, nor is it being compromised).
If we instead deal in hashes up front, we know that we're talking about the same thing. Also, maybe we're not on the same network partition as NPM for some reason. If you've got a hash for the package, you can get it from whoever happens to have it and you can know it hasn't been tampered with. If you're using names you can't really trust it unless you got it from NPM. In addition to the maybe-NPM-is-inaccessable problems, names create additional load on NPM. Odds are we're in the same room when this conversation happens, so the network path between us is much more likely to be stable, high bandwidth, and free of attackers than the path between each of us and NPM.
you can only unpublish.
content hash integrity is verified in lockfiles.
the problem is with dependencies using semver ranges, especially wide ones like "debug": "*"
initiatives like provenance statements [0] / code signing are also good complement to delayed dependency updates.
also not running as default / whitelisting postinstall scripts is good default in pnpm.
modifying (especially adding) keys in npmjs.org should be behind dedicated 2fa (as well as changing 2fa)
The only immutability that counts is immutability that you can verify, which brings us back to cryptographic hashes.
As for lock files, they prevent skulduggery after the maintainer has said "yeah, I trust this thing and my users should too" but the attacks we're seeing is upstream of that point because maintainers are auto-trusting things based on their name+version pair, not based on their contents.
Isn't the whole point that malicious actors usually only have a very short window where they can actually get you to install anything, before shut out again? That's the whole point of having a delay in the package-manager.
There is some sense in giving the early adopters some time to raise the alarm and opting into late adoption, but isn't that better handled by defensive use of semantic versioning?
Consider the xzutils backdoor. It was introduced a month before it was discovered, and it was discovered by a user.
If that user had waited a few days, it would just have been discovered a few days later, during which time it may have been added to an even wider scope of downstream packages. That is, supposing they didn't apply reduced scrutiny due to their perception that it was safe due to the soak period.
Its not nothing, but its susceptible to creating a false sense of security.
All recent attacks have also been noticed within hours of release by security companies that automatically scan all newly released packages published to npm.
So as far as I know all recent attacks would have been avoided by adding a short delay.
But the real solution to this kind of attack is to stop resolving packages by name and instead resolve them by hash, then binding a name to that hash for local use.
That would of course be a whole different, mostly unexplored, world, but there's just no getting around the fact that blindly accepting updated versions of something based on its name is always going to create juicy attack surface around the resolution of that name to some bits.