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.

How I've been doing this is that I have 2 (sets of) backup people. The first set has access to the repo, but can't decrypt. The second set can decrypt (i.e. I have their pubkeys imported), but don't have access to the repo. I've chosen the people such that it's unlikely they collude against me, but in case something happens it's likely they'll be able to get in touch with each other.

There's also other possible approaches: e.g. instead of building a dead man's switch based on the encryption, you can build a dead man's switch based on the data. I.e. you'll use their pubkeys for encryption, but the repo itself is behind a dead man's switch.

> Pushing Malicious Changes to the Pipeline

mean that they already have full access to the repository in the first place? Normally I wouldn't expect an attacker to be able to push to master (or any branch for that matter). Without that, the exploit won't work. And with that access, there's so many other exploits one can do that it's really no longer about ci/cd vulns.