9 ms·
Whatever happened to SHA-256 support in Git
- usr1106 4y agoWhat will come first? IPv4 retired or git SHA-1 repos retired?
- bawolff 4y ago> There is also the risk (which cannot really be made to go away) that the longer hashes used with SHA-256 may break tools developed outside of the Git project Easy fix if that is really an issue, just truncate sha-256. The length of the hash is not the issue that needs fixing (even if its a nice side benefit). > that is only the first step in the development of a successful attack. Finding a collision of any type is hard; finding one that is still working code, that has the functionality the attacker is after, and that looks reasonable to both humans and compilers is quite a bit harder — if it is possible at all. I mean, if you have any sort of binary files in your repo, that's pretty doubtful. The way you mostly do this, is the colliding part is a short binary blob which is embedded, and then the file has code outside the colliding part that does different things depending on the value of the blob. Yeah, getting that past human review with a source code file is going to be tricky. Otoh if you have any sort of binary assets in your git, (this might even include images depending on the attack goals, e.g. goatse attack) this seems a lot more plausible P.s. to be clear, i agree that sha-1dc variant removes most of the urgency.
- phkx 4y agoTruncating the sha256 hashes does sound like a reasonable intermediate step and should also enable interoperability (a guess from my side - if it is only about referencing objects, it probably does not matter how the keys were generated). At some point one could then transition to the full hashes and make the truncated ones an option. I‘m wondering what tooling is heavily dependent on the length of the hashes. Potentially if you want to keep the size of the transmitted data small (at work, we once considered git as a versioned database for an IoT use case…).
- TedDoesntTalk 4y agoYou could SHA-1 hash the SHA-256 hash instead of truncating it :)
- mlindner 4y agoI mean that doesn't help anything as if you collide the SHA-1 hash you automatically get a SHA-256 hash collision.
- awestroke 4y agoThat can't be true
- mlindner 4y agoPerhaps I misinterpreted your comment. If you have X and Y such that X has a SHA1 hash collision with Y, you end up such that SHA256(SHA1(X)) == SHA256(SHA1(Y)). That's why I said what I said.
- nequo 4y agoI think the ancestor comment meant SHA1(SHA256(X)) instead. Not clear to me how that wouldn’t have collisions, too. Just that the underlying commits that generate the collisions would need to look different.
- leipert 4y agoPreviously discussed with hundreds of comments: https://news.ycombinator.com/item?id=31851755 https://news.ycombinator.com/item?id=31851755
- mlindner 4y agoIt's not an issue to use SHA-1 for git. Heck they could have used md5 and it still would have achieved the same. The use of SHA-1 in Git is not for security purposes, it's for accidental data corruption and uniqueness purposes as you're guaranteed to never accidentally get a collision.
- _flux 4y agoGit allows one to sign commits. It would be quite pointless if it was signing mere MD5 hashes.
- ilyt 4y ago...as opposed to signing SHA1 hashes ? Git signs commits, not the whole tree AFAIK
- CorrectHorseBat 4y agoGit signs commit hashes
- seba_dos1 4y agoFor the record, a commit is the whole tree. Git does not store patches, they are generated on the fly by the UI. Trees still rely on hashes to address the actual content though.
- shp0ngle 4y agoIt’s exactly same pointless now. You sign the hash, which is what’s colliding.
- alerighi 4y agoFinding a collision is very hard, not something you will do in minutes, it requires a tremendous amount of resources. For any practical use (like git) that doesn't require an extreme level of security SHA-1 is still fine, and it will be for a lot of years to come.
- boramalper 4y agoDoes someone know why SHA-3 isn't considered instead? Wouldn't its sponge construction—that allows outputting ("squeezing") any amount of data[0]—allow git to maintain backward-compatibility with existing tooling by continuing to use the same 20-byte output? Is it that for d:=160, min(d/2,256) = 80 bits of collision resistance too low to justify the change? [0] https://en.wikipedia.org/wiki/SHA-3 https://en.wikipedia.org/wiki/SHA-3
- nmadden 4y agoYou could just truncate SHA-256 to 20 bytes for that matter.
- boramalper 4y agoIndeed, it's discussed here 6 months ago: https://news.ycombinator.com/item?id=31852651 https://news.ycombinator.com/item?id=31852651 edit: I've assumed that using SHA-3 would be somehow better but their security guarantees seem to be the same (yet).
- newpavlov 4y agoOne issue with SHA-3 is that it currently (unfortunately) lacks hardware acceleration support, while SHA-256 can be ridiculously fast on modern x86 and ARM chips. BLAKE3 is another potential alternative, it can be used as XOF and can be very fast without hardware support.
- jillesvangurp 4y agoBlake3 would be a good choice. Having a fast hashing algorithm is not a bad thing. Integrity checks involve a lot of hash calculations. That's perhaps a reason Git has stuck with sha1 hashes. They are fast enough and good enough.
- openplatypus 4y agoSmall tangent, but what happened with the alternatives? I hear that Mercurial is having a good time at Meta and Google, but hard to find reliable repo hosting. The big three, Gitlab, GitHub and BitBucket are just git. Baazar is Breezy now, but not sure how much life it has in it. Darcs has peculiar distribution via Haskell package managers. Are we "stuck" with git?
- fleg 4y agoFWIW, SourceHut offers Mercurial hosting.
- openplatypus 4y agoFrom the site: Notice: sr.ht is currently in alpha, and the quality of the service may reflect that. :( I miss Kiln from FogBugz (yes, it was years ago)
- zephyr9 4y agoSourceHut is more reliable than GitHub. I mean this in the truest sense of the word, I can rely on SourceHut not to act against my interests, both ideologically and just basic usefulness.
- seanw444 4y agoAgreed. Moved all my stuff from GitHub to Sourcehut. Haven't looked back. Well, okay, I look at the trending repos and star some that are interesting, but I don't host my personal projects on there.
- dist1ll 4y agoI thought so too at first, until the owner changed their TOS to forbid all crypto and blockchain related projects, essentially kicking me off their platform. So no, it's not reliable. The platform is at the behest of a small group of ideologists, who might change their stance on any topic on a whim. GitHub on the contrary continues to host code that has been OFAC sanctioned. I'd rather stay with them.
- pfix 4y agohttps://fossil-scm.org/home/doc/trunk/www/hashpolicy.wiki https://fossil-scm.org/home/doc/trunk/www/hashpolicy.wiki Fossil found a quick way solving this.
- fmajid 4y agoLike SQLite, Fossil is an incredibly well-designed jewel of software craftsmanship. It’s unfortunate market dynamics led to git’s dominance instead.
- mdaniel 4y agoMarket dynamics may be true, but the continued use of git has more to do with workflow than implementation. Fossil makes quite a few dogmatic choices and if one buys into them, then fantastic, but it's for sure not a drop-in replacement for the way teams develop software, and thus would require a teamwide "hard fork" This debate comes up every time git and fossil are mentioned in each other's threads
- rst 4y agoLooks like the git project has a different plan for gradual transition -- but one that's more elaborate and somewhat more fragile. Comment from one of the developers (from prior discussion of the same LWN article): https://news.ycombinator.com/item?id=31856133 https://news.ycombinator.com/item?id=31856133
- c7b 4y agoCould someone explain what exactly the attack vectors would be here? I always assumed the hashes were there just for collision resistance. It would seem that any attacks involving an attacker introducing malicious code through a collision would require a level of system access that would enable more dangerous attacks with less effort and/or less detectability. Curious to learn.
- ilyt 4y agoWell, various variants of spectre attacks were also thought as theoretical decades ago. That's the problem, you never can predict how crafty attacker might abuse the vector of attack.
- Dylan16807 4y agoA basic attack idea is getting someone to accept a patch, while poisoning other servers with an evil version of the patch with the same hash. Then some of the people updating will get the evil version, maybe almost everyone or maybe very specific targets. Poisoning servers, in the most worrying case, just requires the ability to get your evil file into any commit on any branch, and possibly in any repo on the server if they have certain optimizations.
- greatgib 4y agoWouldn't it make sense to introduce a prefix to the hash for 256 bit hashs? For exemple a non hexa letter like z, so it becomes future proof and you can differentiate with the prefix?
- orev 4y agoThe fact that this wasn’t done at the beginning is mind boggling. We already dealt with this problem with Unix passwords using crypt, which was solved exactly this way decades ago. This should be standard for any system using hash algorithms.
- layer8 4y agoHashes are binary values internally, so "z" (or it’s ASCII byte value) already exists as a prefix in SHA-1 hashes (any hash that begins with 7a). The real problem is that existing code assumes that hashes are always exactly 20 bytes in size, and any 20-byte value is a valid SHA-1 hash. There is no way to indicate a non-SHA-1 hash in the binary Git data formats and internal representations processed by existing code. The task is to change those formats and representations, and the related code, to enable such an indication.
- tkone 4y agoSimple answer: github was doing most of this work as SHA1 is a non-allowed hash type for FIPS compliance, which mattered since Microsoft had landed the US DoD JEDI contract. The JEDI contract was cancelled a in 2021 so the work never continued on that workstream. source: former github developer
- FreakLegion 4y agoClarification: SHA-1 is under review but still allowed. The next revision of FIPS 180-4 will certainly start the clock on retiring it, but that's a years-long process.
- layer8 4y agoMore specifically, the current deadline is end of 2030: “Modules that still use SHA-1 after 2030 will not be permitted for purchase by the federal government.” (https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm https://www.nist.gov/news-events/news/2022/12/nist-retires-s...)
- EVa5I7bHFq9mnYK 4y agoIt is often declared that SHA-1 is broken, but in fact still nobody can take code A and find a different code B that hashes to the same SHA1 value, which is what git is concerned about. Even long ridiculed and buried MD5 is still perfectly secure in that sense.
- HyperSane 4y agoBaking SHA-1 so deeply into Git seems like a poor design decision.
- layer8 4y agoYes, algorithm agility was already a known concept when Git was developed, so it’s somewhat surprising that SHA-1 was hardcoded.
- rswail 4y agoThe major git repo hosts need to support it, and given their backing, have no excuse not to. So gitlab, github, bitbucket, aws codecommit et al need to be forced by corporates rejecting their use on security audit ISO27K/SOC2 grounds and they'll move.