In a well-fleshed-out post, Scott Chacon shows how unneecessary Git 3.0’s move to replace SHA-1 with SHA-256 is.
It’s sad to see this community only listening to people because they’re rich: there are a lot of better engineers who knows more than this guy but they’re not “co-creator of GitHub”. I read this title as boot licking silicon valley.
That being said you don’t hash git commits for security reason : YOU SIGN YOUR COMMITS FOR SECURITY. Sorry for the caps but let’s make this visible.
His defense of SHA-1:
Mathematically, for SHA-1’s 160-bit output, the birthday bound means that you would need about 1.4 septillion random files (1.4 quadrillion billion files - 1,400,000,000,000,000 billion - it’s impossible to effectively describe) in a single project to have file hashes accidentally collide.
For the most part the article mostly talks about collision attacks, which quite frankly i think is silly.
He also talks about hashes pointing to other (older) projects using a different hashing algorithm, but can’t the software just detect if its a SHA-1 hash or SHA-256, and fetch it accordingly? He acts like its the end of the world when in my mind most everything can (and probably will) be compensated for pretty easily. It’s reminiscent of the IPv6 fear-mongering.
The thing that gets me is he doesn’t say if the current hashing algorithm or the new one has any support for when hashes do collide. Since that can theoretically happen with both, to me that sounds like a problem worth tackling.
I would have thought they’d prefix the hash with “sha256-“ or something, or even just 256 prefix the hash.
They have different fixed lengths, no prefix needed to tell them apart.
