this post was submitted on 02 Oct 2026
85 points (96.7% liked)

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

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
 

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
[–] enchanted@lemmy.world 27 points 1 week ago (3 children)

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.

[–] panda_abyss@lemmy.ca 6 points 1 week ago (1 children)

I would have thought they’d prefix the hash with “sha256-“ or something, or even just 256 prefix the hash.

[–] setsubyou@lemmy.world 35 points 1 week ago

They have different fixed lengths, no prefix needed to tell them apart.

[–] jsnfwlr@lemmy.ml 3 points 1 week ago* (last edited 1 week ago)

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.