> In particular, as far as I know and as Theodore Ts'o's post describes > better than I could[1], you seem to be confusing preimage attacks with > collision attacks, and then concluding that because SHA1 is vulnerable > to collision attacks that use-cases that would need a preimage attack > to be compromised (which as far is I can tell, includes all your > examples) are also "broken". I understand the differences between the collision and preimage attacks. A collision attack is not that bad for git in a typical use-case. But I think that it's important to note that there are many use-cases which do need a hash safe from collision attack. Some examples: You maintain a repository with gittorrent with signed commits Others can use these signatures to verify it's original. Let's say you include some safe file (potentially binary) from a third-party contributor. That would be fine if the hash algo is safe. Currently there is the possibility that you received a (safe) file which was made to collide with another malicious one. Once you committed (and signed) that file, the attacker joins the gittorrent network and starts to distribute the malicious file. Suddenly most of your clients pulling are infected however your signature is correct. Or, you would like to make a continuous delivery system, where you use signed tags. The delivery happens only when signature is right, and the signer is responsible for it. Your colleague makes a collision, pushes the good-file. You make all the tests, everything is fine, sign and push and wait for the delivery to happen. Your colleague changes the file on the server. The delivery makes a huge mass, and you're fired. Or, let's say you use a service like github, which is nice enough to make a repository for you, with .gitignore, licenses and everything. Likely, you'll never change dose files. Let's say that service made one of those initial files to collide something bad. That means, they can "infect" anyone, who is pulling your repo. Do you need more hypothetical stories? There are a lot. Of course they need a lot of work, and they're unlikely to happen. But it's possible. If you need trust, and gpg signatures that means you need ultimate trust. What's the point in making GPG signatures anyway if you cannot ultimately trust them? You could just as well say: well that's repository is only reachable by trustworthy persons, everything here is just fine and really made by the person named in the "author field". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html