Programming

28764 readers

452 users here now

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

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

founded 3 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev

Github co-creator & Pro Git author skewers Git 3.0's SHA-256 move (blog.gitbutler.com)

submitted 1 week ago by tetrislife@leminal.space to c/programming@programming.dev

23 comments fedilink hide all child comments

In a well-fleshed-out post, Scott Chacon shows how unneecessary Git 3.0's move to replace SHA-1 with SHA-256 is.

you are viewing a single comment's thread
view the rest of the comments

[–] JakenVeina@midwest.social 22 points 1 week ago (2 children)

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.

[–] atzanteol@sh.itjust.works 4 points 6 days ago

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.

[–] asdfasdfasdf@lemmy.world 3 points 6 days ago* (last edited 6 days ago) (2 children)

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.

[–] JakenVeina@midwest.social 5 points 6 days ago

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.

[–] one_old_coder@piefed.social -1 points 4 days ago

If you need security, you must sign the commits.