TiddoLangerak

Fwiw, in plain git, there's 2 dates associated with commits. The author date tells when the content was authored, and doesn't change with rebase. Only the commit date changes. So the correct metadata is already there, and even more precise. It can tell you both when it was authored, and when it's history was last changed.

This is only true if your latency distribution is fully random, which is rarely the case. More often than not, it's the same small group of users hitting most of the p99 because their accounts are simply more resource intensive.

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.

I have a different pubkey per device. I store all the pubkeys in the pass repo, and have a shell script to re-encrypt everything with those keys. So when I add a new device, I just need to add its pubkey, and then re-encrypt on an existing device.

The beauty of pass is that there's a distinction between giving access to the encrypted vault vs giving access to decryption, and you can leverage this.

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.

Am I missing something, or does the step in

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