3 ms·

What you need to understand, is that Git's data structures are essentially annotated Merkle trees [1]. So whatever you sign, be it a tag or a commit, it will be

What you need to understand, is that Git's data structures are essentially annotated Merkle trees [1]. So whatever you sign, be it a tag or a commit, it will be nested sha1 hashes like [someData].sha1([someData].sha1([someData].[aFile]).[someData]).[someData] . And at every level you can conceivable construct a hash collision. So if e.g. you create your own commit on top of a commit of an attacker and sign your commit, you are only signing a (sha1 of a sha1 of a) sha1 of the commit of the attacker. If the attacker's commit was crafted to enable a sha1 collision somewhere, then your signed commit doesn't cover the files and commits you see, but only the sha1 hashes of those objects. This kind of hairy distinction of what a signature was supposed to mean and what it actually covers is what you get with (semi-)broken cryptographic primitives. It's awful and, frankly, unnecessary. [1] https://en.wikipedia.org/wiki/Merkle_tree https://en.wikipedia.org/wiki/Merkle_tree

moonshinefe 10y ago
I appreciate that info, +1. My main point was just if you're dealing with a repository where actors that have those 6 figures to spare to attack you (and that's a minority): 1) you've got to rely on a lot better security than the minimal if at all security provided by git (it assumes a web of trust). If people are signing off with PGP sigs but not watching diffs, you've got big problems. 2) You're probably far more likely to be exploited by far cheaper methods at this point. If they have access to a trusted contributor's keys, it's far more cost effective to slip in other tricks than sha-1 collisions right now. I'd say this is the main point so far, but admittedly maybe not in the future. 3) It sounds like Linus and the git devs have admitted they need to migrate from sha-1, but also I haven't seen any cheap, exploitable PoC for git yet based on this due to how they actually mix in other info instead of raw sha-1 hashes of the files. 4) As far as I know, and I'm sure I'm subject to correction, but there hasn't been a WebKit svn repo-esque calamity yet like what they've experienced dropping 2 sha-1 collision PDFs into the repo in a Git context yet. Again, I'm totally open to new info, but the sky-is-falling attitude right now is what I'm mainly arguing against.
- 5ilv3r 10y ago
  If you drop two identical files into a linux repo then they will be rejected by the maintainers. You don't even need to get into a technical solution to prevent it.

moonshinefe 10y ago

I appreciate that info, +1. My main point was just if you're dealing with a repository where actors that have those 6 figures to spare to attack you (and that's a minority): 1) you've got to rely on a lot better security than the minimal if at all security provided by git (it assumes a web of trust). If people are signing off with PGP sigs but not watching diffs, you've got big problems. 2) You're probably far more likely to be exploited by far cheaper methods at this point. If they have access to a trusted contributor's keys, it's far more cost effective to slip in other tricks than sha-1 collisions right now. I'd say this is the main point so far, but admittedly maybe not in the future. 3) It sounds like Linus and the git devs have admitted they need to migrate from sha-1, but also I haven't seen any cheap, exploitable PoC for git yet based on this due to how they actually mix in other info instead of raw sha-1 hashes of the files. 4) As far as I know, and I'm sure I'm subject to correction, but there hasn't been a WebKit svn repo-esque calamity yet like what they've experienced dropping 2 sha-1 collision PDFs into the repo in a Git context yet. Again, I'm totally open to new info, but the sky-is-falling attitude right now is what I'm mainly arguing against.

5ilv3r 10y ago
If you drop two identical files into a linux repo then they will be rejected by the maintainers. You don't even need to get into a technical solution to prevent it.