Thread

Git 3.0's upcoming SHA-256 default will be a costly mistake

570 points · 536 comments · chmaynard

gandreani · 1790877958 · focus · HN ↗
One of my favorite fun facts about Fossil SCM (another source control by the devs of sqlite) is that they patched their use of SHA1 6 days after the shattered attack was published:
"Both Fossil and Git started out using only SHA1 hashes. But when the SHAttered attack against SHA1 was published on 2017-02-23, the need to migrate to a stronger hash algorithm was recognized. Fossil added the ability to use SHA3-256 as an alternative on 2017-03-01 (six days after the SHAttered attack was first published). SHA3-256 is now the default for all new repositories and check-ins in Fossil, though older check-ins that occurred prior to SHAttered can still use their original SHA1 hash. Hence, no repositories had to be rebuilt and no hyperlinks were broken."
<a href="https://fossil-scm.org/home/doc/trunk/www/hundredandone.md" rel="nofollow">https://fossil-scm.org/home/doc/trunk/www/hundredandone.md
To me it's so interesting watching in realtime Git is still battling with this decision and for Fossil it was just another week of development.
That whole page is fun to read. Another fun fact somewhere else in the docs is that Fossil uses a grow-only set to store commits. They came up with this scheme some years before it was formalized by CRDTs!
1. 6thbit · 1790878355 · focus · HN ↗
  That's impressive. I suppose they had a more flexible architecture to make that change so fast.
  Is there any writeup on why it was easy for them and not for git?
  1. toymin · 1790878759 · focus · HN ↗
    My guess is that it's less about the architecture and more about the blast radius and the number of users
    froh · 1790932399 · focus · HN ↗
    no it's about the architecture and design: fossil enables coexistence of both hashes in one repo
    <a href="https://fossil-scm.org/home/doc/trunk/www/hundredandone.md" rel="nofollow">https://fossil-scm.org/home/doc/trunk/www/hundredandone.md
    27. Fossil allows both legacy SHA1 hashes and newer SHA3-256 hashes in the same repository.
  2. gandreani · 1790878905 · focus · HN ↗
    Hmm probably nothing architecture wise. It's probably just the fact that fossil is developed by way fewer devs.
    From the skim I read of this article it seems both projects arrived at the same solution: support both but make SHA-256 the default.
    kccqzy · 1790904885 · focus · HN ↗
    No it’s different. Git supports both but you cannot mix them in a repo. Fossil allows mixing them in a single repo. This is clearly stated in the link.
    xyzsparetimexyz · 1790926088 · focus · HN ↗
    They should let you mix it in a repo then.
    conartist6 · 1790935629 · focus · HN ↗
    They do apparently. There's information about it in the comment thread on this story on lobste.rs
    rurban · 1790909933 · focus · HN ↗
    SHA3-256 != SHA-256
    gandreani · 1790955495 · focus · HN ↗
    Oops! I admit I don't have much knowledge on hashing algos. I thought it was a shorthand
2. schacon · 1790878734 · focus · HN ↗
  I mean, there are two things here. One is how difficult it is to have a different hashing mechanism. Brian and other heroes in the Git core group have done amazing work to make this _technically_ possible on a repo level. To test some of my theories, I trivially implemented MD5 and an insanely dumb and easily breakable hash backend. It's not _hard_ to change the mechanism now. It's about the community.
  Fossil isn't difficult to change not because it's technically harder for Git but because Git has a community and ecosystem that Fossil does not. The cost is not in the individual project for Git, the cost is because there is _so much_ in Git and this bifurcates everything.
  1. gandreani · 1790878993 · focus · HN ↗
    Agreed! This isn't a tech dig at all.
    To me it's more of a reality of creating a tool with a huge active community and a community of contributors and creating a tool with a small team and small community.
  2. schacon · 1790879228 · focus · HN ↗
    Also, interestingly, Git today does _not_ use a straight SHA1 because of these attacks. It uses `sha1dc`, a slower collision detecting variant that specifically checks for this vector of attacks. So currently, Git's SHA-1 variant is not susceptible to the SHAttered/Shambles attacks.
    jmyeet · 1790954397 · focus · HN ↗
    Sure but that's just kicking the can down the street. It will eventually be susceptible to a collision attack. As will SHA256 btw. What then? Are we doing to go through all this again?
    Online video has handled this. There are various codex, container formats and transport protocols. The TLS handshake does this. The ability to deprecate and replacing the hashing algorithm should've been built in from day 1.
  3. mook · 1790925999 · focus · HN ↗
    As an expansion on that, as far as I know there's only one implementation of Fossil. There was at least a Java one for git, I believe, and I don't think upstream git is related to libgit2 either. And GitHub is doing… something not visible from the outside.
    (… looking at the parent, though, I imagine there might be some information from the inside…)
    sgbeal · 1790934132 · focus · HN ↗
    > As an expansion on that, as far as I know there's only one implementation of Fossil.
    That's is, since only recently, no longer strictly true: the age-old libfossil recently got client sync support, so is now (aside from _serving_ repos) essentially a standalone impl (its own developer still uses fossil(1) stash, patch, and diff -tk features, but otherwise uses libfossil's counterparts).
    Also, Dan Mestas has <<a href="https://github.com/danmestas/go-libfossil" rel="nofollow">https://github.com/danmestas/go-libfossil>, a Go library for working and fossil, and he is also working on <<a href="https://zeitforge.app/" rel="nofollow">https://zeitforge.app/>, a clean-room impl. of fossil (whereas libfossil is largely ported directly from fossil(1)) which even goes so far as to _not_ use an sqlite database for its file storage.
    Dan Mestas and Dan Shearer are working on finalizing RFCs for fossil's sync protocol and artifact format, and zeitforge is created by carefully managing LLMs which are reading that draft (but not the source code of libfossil or fossil).
    gandreani · 1790955438 · focus · HN ↗
    I personally have been using `go-libfossil` in a project! It's got some sharp edges but insanely useful in avoiding CGO and using fossil at the same time
3. fragmede · 1790878893 · focus · HN ↗
  It's easier to make world breaking changes when the world is really small. If git could magically just get everything and everyone to cut over and use git 3.0 in a magic instant, it wouldn't be having this problem.
  1. nofunsir · 1790880741 · focus · HN ↗
    Here's a stoichiometric bird for you:
    :%s/git 3\.0/python 3.0/g
    fragmede · 1790881784 · focus · HN ↗
    Or IPv6 or windows 11.
    :x
    Neovim's lazyvim plugin sucks because it takes over H C and L.
    Dylan16807 · 1790927984 · focus · HN ↗
    Huh wha? What problems are solved by getting all Windows users onto Windows 11 in particular?
    rovr138 · 1790937413 · focus · HN ↗
    Security since Windows 10 and below are not supported.
    <a href="https://support.microsoft.com/en-us/windows/deployment/updates-lifecycle/windows-10-support-has-ended-on-october-14-2025" rel="nofollow">https://support.microsoft.com/en-us/windows/deployment/updat...
    > Windows 10 support has ended on October 14, 2025
    Dylan16807 · 1790943103 · focus · HN ↗
    That's not true because of extended support, but even if it was true, what's the goal here? What benefit does the entire ecosystem share from getting people standardized on 11? Botnets get 25% smaller? That's not some kind of important threshold. Or developers can count on access to a newer mutex API or something? Whereas getting everyone on the same git hash or python or IP protocol streamlines things enormously.
    rovr138 · 1790953798 · focus · HN ↗
    > Whereas getting everyone on the same git hash or python or IP protocol streamlines things enormously.
    You don't think that if we had everyone on the same Windows version we could streamline things enormously?
    For MS, for developers, for hardware manufacturers, and so on to be able to deploy, for example, ipv6 since everyone is on the same stack? Same stack, same bugs, same fixes.
    Dylan16807 · 1790961843 · focus · HN ↗
    Microsoft can already put out an update to both windows 10 and 11 at the same time. They occasionally do this for bugfixes. That hits basically all Windows users.
    The difference in effort between updating one versus two very similar code bases is minor, especially when "Windows 10" and "Windows 11" each refer to multiple versions already.
    For drivers you only need one version to support both.
    IPv6 has been built into Windows for ages. If you think they can force toggle it or something, that won't work at all and deleting Windows 10 wouldn't make it easier.
    rovr138 · 1790968947 · focus · HN ↗
    So you're there's exactly 0 effort in managing things for multiple Windows versions, for anyone along the entirety of the ecosystem? From MS developer, third party developer, hardware, drivers, users, etc?
    How about testing? Do you think that there's no testing put out when a fix has to go out for 2 OS, regardless of how similar they are?
    > What problems are solved by getting all Windows users onto Windows 11 in particular?
    I have given a few. If you don't want to see it, that's fine.
    Dylan16807 · 1790971034 · focus · HN ↗
    Exactly 0? I said it's not "streamlined enormously".
    I would estimate that supporting both windows 10 and 11 is a single digit percentage harder than supporting just one of them.
    > I have given a few. If you don't want to see it, that's fine.
    Where? You said something vague about streamlining, and the only concrete example was something about "deploy ipv6" which Microsoft did back in Vista.
  2. samus · 1790918111 · focus · HN ↗
    It seems Fossil can use multiple hash algorithm within the same repository. Yes, that decreases overall security since the hashes pointing to older objects can still be spoofed.
4. bawolff · 1790906769 · focus · HN ↗
  in fairness, git switched to sha1-DC in may 2017, so they were only a few months late in mitigating it.
  1. Karliss · 1790928731 · focus · HN ↗
    Isn't sha1-dc just checking for a small list of hard coded disturbance vectors? Meaning that script kiddies can't easily reuse exact values that researchers spent a bunch of time precomputing. That's far from being a good long term solution.
    someonebaggy · 1790941269 · focus · HN ↗
    Yes.
    bawolff · 1790976730 · focus · HN ↗
    I'm not an expert on this but my impression is its a bit in the middle. It isn't a great long term solution, but finding new disturbance vectors is very hard. Its not like someone can just go find more on a whim.
5. hedora · 1790911493 · focus · HN ↗
  The saga continues with that proposed terrible github UI in the article (from a github cofounder!)
6. ncr100 · 1790921027 · focus · HN ↗
  Feels like Leadership of Fossil SCM is better than that for git.
  (Because: This very old problem is ongoing with git, and is closed with Fossil.)
  1. gb67890 · 1790941789 · focus · HN ↗
    can I have your email to get in touch
7. somat · 1790952522 · focus · HN ↗
  I always liked the ipfs concept of a multihash where a hash algorithm id is stored with the hash, I don't know how well it worked in practice, but in theory all applications of the protocol are now forced into a world where there are multiple hash formats and it can and will change.
  1. jmyeet · 1790954216 · focus · HN ↗
    We don't need that. Introducing an unknown hash algorithm itself is a security issue.
    This problem isn't hard or new. Just look at things like a TLS handshake. You need to separate the protocol from the storage implementation.
    I personally believe the initial Git programmers were too in love with the efficiency of doing a bitwise 160 bit comparison on the stack and they sacrificed the known issue of changing the algorithm to do it. A decade earlier the same thing had happened with MD5.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.