Whatever happened to SHA-256 support in Git? [LWN.net]

Whatever happened to SHA-256 support in Git?

Posted Jun 23, 2022 14:19 UTC (Thu) by LtWorf (subscriber, #124958)
Parent article: Whatever happened to SHA-256 support in Git?

Wouldn't the people that care about security just sign the commits?

to post comments

Whatever happened to SHA-256 support in Git?

Posted Jun 23, 2022 14:35 UTC (Thu) by dtlin (subscriber, #36537) [Link] (16 responses)

Git signs the commit or tag object, not the whole file tree. So if you don't trust SHA-1, GPG doesn't add any security - the file content under a signed commit or tag could still be replaced.

Whatever happened to SHA-256 support in Git?

Posted Jun 23, 2022 19:10 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (2 responses)

Furthermore, all currently feasible SHA-1 attacks are collision attacks - i.e. attacks in which the same person creates both the "good" commit and the "bad" commit. Signatures are primarily designed to deal with the case where the "good" and "bad" commits are created by different people (i.e. they are used to prove that a given commit was authored by the person identified in its metadata, and not an imposter). You can also use signatures to prove that some third party has reviewed the commit and believes it to be non-malicious, but to my understanding, that is not the typical use case (and, as you say, it is defeated by the collision attack anyway).

Whatever happened to SHA-256 support in Git?

Posted Jun 24, 2022 0:07 UTC (Fri) by wahern (subscriber, #37304) [Link] (1 responses)

Chosen-prefix attacks have already been demonstrated.[1] SHA-1 is as dead as MD-5. Which is to say, not entirely, but nobody who cares about their reputation wants to be in the company of those quibbling about how it can still be used for this or that.

[1] https://eprint.iacr.org/2020/014.pdf

Whatever happened to SHA-256 support in Git?

Posted Jun 24, 2022 1:27 UTC (Fri) by bartoc (guest, #124262) [Link]

Well, md5 has a (somewhat computationally theoretical) full preimage attack, and it's chosen prefix attacks and general collision attack algorithms are somewhat faster than those for SHA-1. I kinda suspect it's cheaper to social engineer code into most git repos than it is to try and find a SHA-1 collision (not to mention simply finding and inserting the colliding object may not be enough to cause the modified code to spread).

It is about time to start switching over to sha-256, but of all the overdue migrations away from harmful stuff in the world SHA-1 git repos are .... not that harmful.

Whatever happened to SHA-256 support in Git?

Posted Jun 23, 2022 20:04 UTC (Thu) by walters (subscriber, #7396) [Link]

I started https://github.com/cgwalters/git-evtag before the sha1 breakage, I think it still makes sense. May try at some point to get it into git again.

Whatever happened to SHA-256 support in Git?

Posted Jun 24, 2022 3:18 UTC (Fri) by brasic (guest, #159230) [Link] (11 responses)

> Git signs the commit or tag object, not the whole file tree. […] the file content under a signed commit or tag could still be replaced.

Fortunately this is incorrect! Well, the second part is incorrect; the first is quite right but doesn’t imply what you think it does.

Every git commit is the root of a merkle tree, or as the kids call it, a “blockchain”. A git commit object id is the hash of a string which includes among other things the commit’s immediate parent object ids, and the commit’s root tree object id. Here is the canonical serialization of a commit, the input bytes passed to the hash function: https://github.com/git/git/blob/39c15e485575089eb77c769f6...

The tree oid is also the root of a separate merkle tree which recursively hashes the contents, file names and permissions of every file in the repo.

Since the input string which is hashed to produce the commit oid includes the tree oid, the contents of every file in that commit and all prior ones are part of the id and any change to any file will produce an entirely different object id.

The actual string which is signed is exactly the canonical serialization above. Then the sig is added to a header and the object id is computed (now including the signature as a has component)

So you’re quite right that only the commit is signed. But because of the magic of git, signing a commit is equivalent to signing the whole tree and all of history!

Whatever happened to SHA-256 support in Git?

Posted Jun 24, 2022 7:22 UTC (Fri) by azumanga (subscriber, #90158) [Link]

I think there is (to me) a misunderstanding of "whole tree".

The problem is, while yes the hash "represents" the whole tree, if SHA1 is broken signing a hash for either a single commit, or whole tree, are both in practice useless.

Whatever happened to SHA-256 support in Git?

Posted Jun 24, 2022 14:17 UTC (Fri) by angelsl (guest, #144646) [Link]

Yes, so you could replace the contents of a file (blob object), or the tree object, or the commit object itself, by finding a hash collision.

Whatever happened to SHA-256 support in Git?

Posted Jun 25, 2022 4:46 UTC (Sat) by alison (subscriber, #63752) [Link]

> Every git commit is the root of a merkle tree, or as the kids call it, a “blockchain”. A git
> commit object id is the hash of a string which includes among other things the commit’s
> immediate parent object ids, and the commit’s root tree object id.

Is the algorithm used by TPMs also a merkel tree?

Whatever happened to SHA-256 support in Git?

Posted Jun 27, 2022 14:02 UTC (Mon) by KaiRo (subscriber, #1987) [Link] (7 responses)

Please do all of us a favor and don't use the word "blockchain" when you obviously don't know what makes something one. While blockchain usually use merkle trees, that doesn't mean a merkle tree is a blockchain, it's (usually) part of one. There is enough FUD and scamming around this area, it's neither useful to you to join into that muddy crowd nor is it useful to those of us who are trying to make decent and honest use out of the social engineering and technology combination that actual blockchains represent.

Whatever happened to SHA-256 support in Git?

Posted Jul 5, 2022 22:17 UTC (Tue) by koh (subscriber, #101482) [Link] (6 responses)

Please do all of us a favour and enlighten us as to what technically (usually) are those fundamental differences you're hinting at.

Whatever happened to SHA-256 support in Git?

Posted Jul 6, 2022 3:18 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (5 responses)

The key element which sets a blockchain apart from an arbitrary Merkle tree (or DAG) is the Byzantine consensus system which ensures that there is only *one* dominant chain in the distributed system. Git repos are organized into one or more Merkel trees, but it's a federated system where each node is a silo with its own data, not a distributed one where all the nodes (eventually) come to share a single Merkle root with new "blocks" being added to a common "chain".

Whatever happened to SHA-256 support in Git?

Posted Jul 6, 2022 14:04 UTC (Wed) by geert (subscriber, #98403) [Link] (3 responses)

Sounds like Linux kernel development, where (ideally) all forks end up being merged into Linus' tree, eventually...

See James Bottomley's closing keynote at OLS2007 (https://www.linux.com/news/ols-closes-keynote/).

Whatever happened to SHA-256 support in Git?

Posted Jul 6, 2022 14:34 UTC (Wed) by farnz (subscriber, #17727) [Link] (2 responses)

The distinction is that in the Linux development model, Linus is a single point of failure - the consensus algorithm in the federated git tree world is "we trust Linus". In a blockchain, the consensus algorithm will choose a tree from the set in the federation such that no individual tree in the federated set is "more trusted" than others - if Linus were to go rogue or go on vacation, a blockchain development model would choose someone else's tree as "mainline Linux" automatically.

This is the key to the blockchain's difference from other Merkle trees - in a blockchain, consensus is formed automatically and does not depend on humans choosing trusted people, while in most Merkle trees, the consensus decision depends on humans making trust decisions.

It's mathematically neat that we can have consensus without needing trust, but it's not necessarily a practical result.

Whatever happened to SHA-256 support in Git?

Posted Jul 6, 2022 15:21 UTC (Wed) by excors (subscriber, #95769) [Link] (1 responses)

> in a blockchain, consensus is formed automatically and does not depend on humans choosing trusted people

...except when, say, the core developers can't agree on a technical change for the project and so they fork the blockchain and now you've got two versions that both claim to be authoritative, and they have to fight it out on social media to convince users/miners/exchanges/etc to support their side. Maybe the mathematical model is trustless but that's because it's modeling an unrealistically abstract version of the problem - the practical implementation is never trustless, it's just obscuring who you're having to trust. (And as demonstrated over and over again, users often end up having to trust people who really don't deserve that trust.)

Whatever happened to SHA-256 support in Git?

Posted Jul 6, 2022 15:46 UTC (Wed) by farnz (subscriber, #17727) [Link]

To be fair, that's an issue because you're choosing between two different blockchains, each of which does the trust thing automatically.

And that sort of problem is what I meant by saying that it's mathematically neat, but not necessarily practical - being able to form a consensus without trust is cool, but there are other dimensions involved beyond simply forming a consensus, such as which blockchain to trust.

Whatever happened to SHA-256 support in Git?

Posted Jul 7, 2022 11:06 UTC (Thu) by koh (subscriber, #101482) [Link]

If I understand correctly: Merkle DAG + automated choice of the "mainline" branch to add nodes to + automated distribution of all nodes/commits in a network.

Not sure about the "all" in the last part, but that helped, many thanks!

Whatever happened to SHA-256 support in Git?

Posted Jun 23, 2022 14:42 UTC (Thu) by smoogen (subscriber, #97) [Link]

Then you need to build into your checkout tooling to check that the signatures are actually valid. That means knowing what this 3rd party person's key is, how valid it is to that project, etc. I expect that like most of the usage of 'signatures'... it would be dictated but turned off in any build system because it is so hard to keep working. Most developers would rather have someone giving them hacked code than deal with GPG signature problems on a checkout.

Which is why saying 'you can't use SHA-1' is an easier dictum from a security groups compliance method. You know that the signature's etc would be better, but you know within 2 minutes of saying using it would be ok that it would be turned off in the name of 'get that build out the door'.