Another case where git uses SHA1 is submodules. You audit libfoo's well-regarded v1.3.3.7 release, commit badc00fee, decide it's suits your need and use that co

Another case where git uses SHA1 is submodules. You audit libfoo's well-regarded v1.3.3.7 release, commit badc00fee, decide it's suits your need and use that commit as a submodule in your project. You assume resolving the submodule will always give you same code (or fail). Alas, libfoo author has been corrupted by The Adversary and later arranges for same hash to resolve to different code. (currently we're talking of collision not 2nd preimage, but libfoo's author could have been planning it all along, before your audit.) ["libfoo" here is fictional, I'm not refering to any of the projects actually named that.] Similar things happen when Git hashes are exchanged by any side channel. The ability to use strong hashes as pointers to content inside any other data is the whole beauty of Merkle DAGs. Git submodules just happen to be one such channel that's part of git, but I think it's important to accept that git commit hashes are widely used outside git itself. P.S. I see git-evtag already covers submodules. Nice.