Github co-creator & Pro Git author skewers Git 3.0's SHA-256 move
18 days ago by Life is Tetris to c/programming
In a well-fleshed-out post, Scott Chacon shows how unneecessary Git 3.0's move to replace SHA-1 with SHA-256 is.
I would have thought they’d prefix the hash with “sha256-“ or something, or even just 256 prefix the hash.
Like how y2k wasn't a worry.
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.
There's people who seriously think commit hashes are there for security purposes? Furthermore, there are git MAINTAINERS that think this?
How absurd. Author is completely right, making SHA-256 the default implementation serves no purpose. SHA-1 is a completely valid algorithm for non-security use cases, which is precisely how git uses it. This is a solution looking for a problem.
I think he's maybe overblowing the impact of this change. Realistically, the only ones who are going to be impacted are the folks who maintain git-related tools and forges, as he mentions. The rest of us probably won't even notice. But that's still a ton of pointless work for those folks.
I think he's maybe overblowing the impact of this change.
Maybe... But I don't look forward to working with the dozens of IT folks at my company who all installed git once and have never upgraded. This will be multiple meetings, show up on slide decks, break builds...
It's going to be a right pain for nothing.
Wait, they don't affect security? Wouldn't a hash collision mean pulling that hash from GitHub would pull wrong code? Or maybe delete code? I'd assume the hash is used as a lookup key in a database somewhere.
You also pin dependencies to specific hashes for security reasons.
The blog post lays it out pretty well.
The vulnerability of SHA-1 is that it's possible for an attacker to find colliding hashes. But that's not really an attack vector, because it's not like they can find aatching hash for just ANY input. In order to pull off an attack, using a hash collision, an attacker would have to already be trusted within the controlling system, in which case they can do a hell of a lot worse than swapping out a file.
Like you say, the hash is used as a lookup key within the git repo's database. The requirement for that is uniqueness, which SHA-1 still fulfills just fine. The trust isn't in the database lookup, the trust is in the systems that controls access to and distribution of that database.
As the article points out, Linus Torvalds himself said as much in 2005, when he first wrote git:
I really think people should not consider the sha1 the "security". The real security is in distribution.
If you need security, you must sign the commits.
Why did they skip the 255 versions?!
/s
Every time I use the shitty command-line flags of git, there is a laugh track.
This post misses, uh, a few important things that get mentioned in the lobsters comments: https://lobste.rs/...
Can anyone share an invite please?
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.
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)!
@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
go to feed...
@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
go to feed...
His defense of SHA-1:
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.
save