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

storyinmemo

Yes every repo is either one or the other but you fix that by rehashing the entire repo. Everyone can do this independently. It's entirely possible to maintain to identical repos in SHA1 and SHA256 mode but for the most part I suspect once updated people will simply pull down the new repo and use git 3.0 as a required version. As migrations go, it's reading as simple to me. You'll just have to backpoint the commit signatures. I must assume there's a backwards compatible reference for them in git 3, right? Or drop them and reference the old structure in a dire pinch.

bkolobara

I run a small git/jj forge and for us it's already painful dealing with this. Can't imagine how GitHub is going to handle it.

nicoburns

From what I'd read, SHA256 in git is showing every sign of being another IPv6. In particular: - It's implemented in a non-backwards-compatible way - The benefits over the older model are a bit nebulous - There's a large amount of tooling that needs to catch up, and little sign that there is movement there

ltbarcly3

This seems like Y2K fud. The alternative to making sha256 the default is to leave sha1 the default. Nobody changes to sha256. sha1 is broken in 10 years. Suddenly everyone has to switch all at once on the same day because it is a critical security issue, but github never implemented sha256 because they didn't have to. This would be a major problem. This is very very easy to fix if you run into it. 1. Adopt git 3.0 if you can with sha256. 2. If you can't use sha256, set the config to put things back to sha1. Wherever you need to do this you probably already set dozens of ENV vars or settings, just add a new one. Or write a 15 page analysis about how the above is so hard people will probably just find it catastrophic to even think about.

amluto

I don't understand why Git is not making the SHA-1 and SHA-256 modes far more compatible with each other. SHA1-hashed objects should be able to refer to SHA-256-hashed objects, although this seems somewhat pointless. But SHA-256-hashed objects should also be able to refer to SHA1-hashed objects, with a major caveat: if those objects themselves are part of a collision pair, then there is a genuine problem. But this is avoidable! Suppose that Linux decided to migrate to SHA-256. The upstream project could choose a pair of dates, say January 1 2027 and March 1 2027. Up to the first date, maintainers would be welcome to submit hashes of objects that are not yet in the repo but that they think they might submit later on, and, on that date, the upstream tree would finalize the list of these objects and reference it in the repo (with a new mechanism for this purpose). Effective the second date, the repo would start publishing SHA-256 commits and would never again accept a SHA1-hashed object that was not in the repo at the cutoff date or referenced as part of the Jan 1 block. And now it would be impossible to get a new SHA1 collision in to the repo. The only new git features needed would be: a) actual compatibility so that a SHA-256-hashed object could reference a SHA1-hashed object b) a new object type that's a list of allowed SHA1 hashes (or probably a tree of them) that is itself hashed with SHA-256 and a mechanism to link to one of these from a commit c) a policy mechanism to set a repo to only allow SHA1-hashed-objects that a reachable from a preconfigured SHA-256-hashed commit

thunderfork

A lot of replies here seem to be asserting that this "isn't that hard" without addressing the thing that makes it most hard: submodule compatibility and the breadth of tooling

quotemstr

Would the author feel the same if git had used MD5 instead of SHA-1?

purpleidea

This means, if you migrate your repo, every single commit message that contains text like: "please see commit <sha1>" will now be broken. This will be a train wreck. I hope they don't release before adding compatibility modes to keep the existing sha1's around in the database.

MBCook

So they’ve been talking about this for many years, planning, and finally announce when they’re going to switch the default. So this is the right time to post that everything they’re doing is wrong? Did you engage in all the discussions about it and how best to handle it? Whether SHA-256 was the best solution? I don’t see anywhere that it talks about alternate proposals or why they might have been better. Why the particular suggestions here were rejected. This seems like a bunch of Monday morning quarterbacking.

pavon

Ugh, I didn't know that SHA-1 submodules wouldn't be supported in SHA-256 repos. That changes the transition from painless to a major dumpster fire. Having to maintain converted forks, and use different hashes from upstream is going to be a mess.

sigmar

>it will be an incomprehensibly expensive and ultimately valueless and avoidable global nightmare. thought "costly" in the title and "incomprehensibly expensive" in the subheader meant this piece would discuss how much less performant sha-256 is on modern machines, but didn't see anything. isn't there hardware acceleration? how much worse is it?

kpcyrd

This article is full of mistakes and misleading claims: 1) It's claiming SHA1 insecurity is theoretical, while SHAttered from 2017 was specifically a pratical proof of concept. The only reason Git wasn't affected, is because they didn't bother bruteforcing a git-blob prefix. 2) It's claiming collision attacks don't matter, only second-preimage attacks do. This is incorrect, collision attacks are enough for code-smuggling problems, when two repositories are on the same git commit (verified by the full commit hash), yet contain different code in their git checkout. 3) The Linus quote "The real security is in distribution" is arguing that "git's content-addressed system should not be used to address content". It's arguing that, in case of curl|sh, you shouldn't use a sha256sum-gate to pin the content to something you've reviewed, you should instead ensure curl is fetching from an https server.

Magicrafter13

The first reason the author lists for why this will be bad is only an "issue" on Git hosts that don't allow repo creation on push (which is brain dead of GitHub). Any other host, you push your new repo, and it will see the hashing algorithm, and receive the contents accordingly. Submodules is a legitimate argument against this, though I don't know how widely this feature is actually used, and similar to the arguments in favor of switching the default branch from master to main, this is simply a setting which can be changed. I do like the idea of commits having both hashes, and am surprised that idea has not been explored further. Generally though, I think the author's strongest argument is simply that the change isn't strictly "needed", and all the other issues presented aren't the strongest arguments against change.

r3trohack3r

> We can go through years of this SHA-1 to SHA-256 migration and then quantum computers break 256 and we're back in the same stupid boat again. SHA-256 is considered quantum safe by the NIST and is left out of PQC migration guidance entirely.

OkayPhysicist

Can someone more cyber-pilled than me explain what the actual risk with Git hashes being susceptible to collision attacks is? Obviously accidental collisions are problematic, but to my understanding the probability of that is still approximately zero. Best I can tell, all a forced collision would do is let someone who already has control of a repo modify the history in a far from plausibly deniable way. Which in practical terms, they already could do simply by replacing the whole thing, because who's out here using git hashes as a security tool? Every pinning I've ever seen has been to tags (which can be modified at will), or hashes of the actual payload (which doesn't need to be the same as what git uses).

njt

schacon: Really like the "Independent Tree Hash Headers" idea. How difficult would this be to get this functionality into git? Would it cause any breaking changes with older versions? Have you discussed this with any git devs to see if they are open to adding it?

6thbit

I thought this would be a snark but it's an extremely well put together argument against the "Hashmageddon". If you're replacing the weakness of SHA-1 just by going to another algorithm, you better be prepared to go to the next one when sha256 collisions happen, and it doesn't sound like git's design would be easy to modify for this type of crypto agility. I do like their proposal for using signatures to establish trust and allow swapping sha256 for whatever comes next.

JaumeGar

The xz backdoor is basically his point in practice — that was a maintainer-trust compromise, not a hash collision.

gandreani

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!