>With specific commit hashes you can verify the the version you are building with in production is the exact same code as the one your security team audited pri

>With specific commit hashes you can verify the the version you are building with in production is the exact same code as the one your security team audited prior to release (assuming git has fixed its hash collision vulnerability) Can we take a moment and point out that the hash collision vulnerability is still at large with no ETA? This is after years of it being considered insecure I feel like this point continues to be glossed over with versioning systems that depend on git commit hashes. Bruce Schneier warned in February 2005 that SHA needed to be replaced. (https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html https://www.schneier.com/blog/archives/2005/02/cryptanalysis...) Git development didn't start until April 2005. So before git was even developed, SHA was identified as needing to be deprecated. So now, 13 years later, this is still an issue.