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."

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!

▲

bawolff an hour ago | parent | next [-]

in fairness, git switched to sha1-DC in may 2017, so they were only a few months late in mitigating it.

▲

6thbit 9 hours ago | parent | prev | next [-]

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?

▲

toymin 9 hours ago | parent | next [-]

My guess is that it's less about the architecture and more about the blast radius and the number of users

▲

gandreani 9 hours ago | parent | prev [-]

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 an hour ago \| parent [-]
		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.

▲

schacon 9 hours ago | parent | prev | next [-]

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.

	▲	schacon 8 hours ago \| parent \| next [-]
		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.
	▲	gandreani 9 hours ago \| parent \| prev [-]
		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.

▲

fragmede 9 hours ago | parent | prev [-]

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.

▲

nofunsir 8 hours ago | parent [-]

Here's a stoichiometric bird for you:

:%s/git 3\.0/python 3.0/g

	▲	fragmede 8 hours ago \| parent [-]
		Or IPv6 or windows 11. :x Neovim's lazyvim plugin sucks because it takes over H C and L.