3 ms·
Can't you sort of do that by pinning on the commit SHA already? It's bad that that's not the ONLY way to do it, but at least it's something.
by delusional 2y ago
Can't you sort of do that by pinning on the commit SHA already? It's bad that that's not the ONLY way to do it, but at least it's something.
- dboreham 2y agoYou can also fork all the dodgy actions you consume.
- Halan 2y agoNot really a solution at enterprise level and it exposes to the risk of likely not patching them as often
- neallindsay 2y agoYes but SHA1 collisions are easy enough to engineer, so even then compromise is probably possible. (I don't know how hard it is to push a different object to an existing SHA on GitHub—I'm guessing that you probably have to remove all references to the original object at that SHA?)
- SAI_Peregrinus 2y agoSHA1 collisions are easy, but nobody has publicly revealed a second-preimage attack. With a collision you create two inputs that hash to the same output, with a second-preimage attack you are given one existing input & have to find a second input that hashes to the same output. Collisions are much easier since you can control both inputs.
- neallindsay 2y agoThat's a good point. Setting up a benign release first that you have engineered a same-hash malicious release you can swap in later is a higher bar than gaining control of a repo and immediately replacing a popular release.
- Halan 2y agoYes and I do that and Dependabot supports it but most people wouldn’t bother