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.
If you know of write-ups by others on this, you are welcome to share. It was a pretty long post, so I mentioned who authored it. If it was on, say, LWN, I wouldn’t have prefixed anything to the topic. It looks like it also helps people to avoid rich-man blogs (if they want to)!
But signing keys can be stolen, have to be updated, revoked etc. A secure hash is an elegant way to say “this repo contains what I want”
This post misses, uh, a few important things that get mentioned in the lobsters comments: https://lobste.rs/s/bytzgl/git_3_0_s_upcoming_sha_256_default_will_be
Thanks for sharing.
Why didn’t I know lobsters before? This look 1000 times better than HN… oh you can’t join. Makes sense it isn’t that known.
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.
Collision concerns make sense. If you manage to get two different files with the same hash, that will cause issues for your repo - the concerns over a collision justify the move to SHA-256 though.
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.
deleted by creator
Madness
We had a similar stupid issue at my last job. Someone made an edict that all Sha-1 and md5 references in the code must be removed for security reasons.
Why did they skip the 255 versions?!
/s
Don’t be insane, they only skipped 254 versions
Filler episodes.
Every time I use the shitty command-line flags of git, there is a laugh track.
I’m not qualified to talk about it but Hacker News has arguments against his post: https://news.ycombinator.com/item?id=49924179
You’re probably more qualified than most HNers, just less confident, less inclined to indulge in performative expertise and pseudo-intellectual posturing, and more resistant to joining the circle-jerks with those who do indulge.
