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

▲

schacon 9 hours ago | parent | next [-]

Emily's talk does a pretty good job of summarizing the issues with intermixing the hashes: https://youtu.be/eJJp0RE7cd4

▲

RJIb8RBYxzAMX9u 9 hours ago | parent [-]

I skimmed the video, and I didn't quite catch that. Near the end of the video, however, she did mention that interop is in the works[0].

In any case, even if Git 3.0 were completely incompatible, it would suck, but it's not the end of the world. You just treat it as if you were migrating from one SCM system to another. CVS -> SVN -> Perforce -> Git -> Git 3.0 -> [...] been-there-done-that. This is something that both open-source and commercial projects have had to deal with over the years.

Or maybe it would be a repeat of Python 2.x -> 3.x. ¯\_(ツ)_/¯ With AI assistance, hopefully porting the tooling over may go a lot quicker and smoother.

[0] https://www.youtube.com/watch?v=eJJp0RE7cd4&t=1134s

▲

ba1afd89f34cb23 9 hours ago | parent | next [-]

Her entire section 2 (starting at 6:12) is basically about why git does not and will never allow mixing of SHA1 and SHA256.

The interop discussed is using copybara as a copy tool to move data from SHA1 based repos to SHA256 based repos and vice versa.

▲

RJIb8RBYxzAMX9u 8 hours ago | parent [-]

Thanks. I went back and re-watched that part, and her point's that "[a] tree's cryptographic strength is equal to the weakest hash algorithm anywhere in the tree," and that's fair. I also understand why Git 3.0 may not want to give user the choice, though I would still rather it be given.

	▲	amluto 7 hours ago \| parent \| next [-]
		> "[a] tree's cryptographic strength is equal to the weakest hash algorithm anywhere in the tree" This is simply wrong IMO, for two reasons: 1. The attack on SHA-1 is a collision attack. Once you have frozen a hash, you cannot attack it with existing cryptanalysis. If there were a preimage attack it would be a different story. 2. Even if there were preimage attacks, one could freeze a mapping from SHA1 hash to SHA-256 hash. In fact, #2 seems like en excellent design. Objects could reference such a mapping, and a repo could disallow conflicting mappings (the mappings would only be accepted if the mapped objects are reachable from the mapping and the mapping is correct).
	▲	schacon 8 hours ago \| parent \| prev [-]
		They do give the user the choice, but the default is changing. My point is not necessarily to rip out the SHA-256 option, but simply to not make it the default. Because then people will create repos in that format that do not understand the ramifications, where the opposite should be true.

▲

schacon 8 hours ago | parent | prev [-]

My point is not that it's the end of the world (or the end of Git), but that it will be painful and unclear and confusing to lots of people. That would be fine if it made a huge difference in trust or protection, but it's the wrong way to do that.

▲

mort96 8 hours ago | parent | prev [-]

Hm but the date is stored inside of the commit. The only way we can know that a commit's date is authentic... is through its hash. If I can forge commits with any SHA1 hash at will, I can make a repository whose head commit has the same SHA1 as the one in torvalds: /linux but where any commit was replaced by a malicious commit with the same SHA1 and a fake date. You have no way to detect that my repo is inauthentic other than through a deep history comparison. The whole idea behind a merkle tree is that just checking the hash of the top is sufficient to know the identity of the whole tree.

I don't know what the solution is, but I'm inclined to believe that any repo with a single SHA1 commit is as weak as a repo with all SHA1 commits.

▲

amluto 7 hours ago | parent | next [-]

The date that a repo receives a commit is known to that repo. And a repo can stop accepting new SHA1 objects. And a SHA256 object could have a flag that says that no SHA1 objects may ever reference it.

▲

mort96 7 hours ago | parent [-]

The design of Git, as a Merkle tree, is meant to allow for use cases like this:

* I host a mirror of the Linux git repo.

* You download Linux from my mirror.

* You check out a commit, say fd179f8a05be3ccae366b9b96e176b51fbe54aab, which you know is a genuine commit through some out-of-band mechanism (mailing list, GitHub web interface, a line in a Nix file, whatever).

* You check whether the repository I gave you is legitimate or not by re-computing the hash of the commit which I claimed was fd179f8a05be3ccae366b9b96e176b51fbe54aab. If it comes out to be fd179f8a05be3ccae366b9b96e176b51fbe54aab, you know it's legitimate. If it doesn't, you know it's fake.

This is a completely normal use of Git. People download from mirrors all the time. People rely on commit hashes to identify a specific source tree. People trust that if whatever the mirror gave them hashes to the right value, it's genuine. That way, you don't have to trust the mirror.

If I can forge my own commits to have any hash I want, this whole model breaks down. I can replace some old commit in the repo with my own forged commit with the same hash, and when you download a copy of the Linux repo from my mirror, you'll receive a repo with malicious content, but it'll hash to the same fd179f8a05be3ccae366b9b96e176b51fbe54aab hash as a genuine repo would. This breaks the security model of Git.

▲

amluto 6 hours ago | parent [-]

> You check out a commit, say fd179f8a05be3ccae366b9b96e176b51fbe54aab, which you know is a genuine commit through some out-of-band mechanism

That's a 160 bit hash, which is SHA-1, which has the security properties of SHA-1.

Suppose you check out a commit with a given SHA-256 hash. That commit object represent the root of a tree where all the edges are hashes (and types, etc). I'm suggesting one of two designs:

a) (Simpler but weaker) If Linus has published that commit, then he is confident that he hasn't pulled in any too-new SHA-1 hashes and that there are no collisions present in what he thinks the tree is. So, by induction on the traversal depth, there is only one actual object identified by each edge, and those objects contain the hashes of their child edges, so those hashes are all correct.

This breaks if there is a malicious collision already in the tree.

b) (Stronger but higher overhead and more complex) There would be an object or objects, discoverable from the root by following only SHA-256 edges, that encode a duplicate-free mapping from SHA-1 hash to SHA-256 hash. The client finds and parses that and then, as it traverses the tree, each time it reads a SHA-1 hash, it computes the SHA-1 and SHA-256 hash of the referenced object, verifies that the pair is in the mapping and also verifies that the SHA-1 hash matches what the edge requires.

I think that (b) is genuinely cryptographically secure in the sense that, if you can construct a commit that has the same SHA-256 hash as an official upstream commit but different contents, then there is necessarily a SHA-256 collision.

▲

mort96 5 hours ago | parent [-]

For A), I don't understand what the point is? I never mentioned what Linus is confident about, I talked about what you can verify when you pull from my mirror. I could replace a commit from 2010 with a malicious one

For B), I would think this could work, but it's a completely different solution from what you proposed and what I responded to.

▲

amluto 4 hours ago | parent [-]

> I could replace a commit from 2010 with a malicious one

How? Remember, there are (currently, anyway) no known SHA-1 preimage attacks.

▲

mort96 3 hours ago | parent [-]

We're discussing a hypothetical situation where SHA-1 gets even more broken. From my original comment in this thread (https://news.ycombinator.com/item?id=49924179#49925367):

> If I can forge commits with any SHA1 hash at will

We probably don't want to wait until there are practical pre-image attacks discovered to change away from SHA-1.

	▲	amluto 3 hours ago \| parent [-]
		This is a fair point. I think I stand by my second proposal. I also think it's absurd that, after all these years, upstream git still can't figure out a credible migration plan.

▲

PunchyHamster 3 hours ago | parent | prev [-]

If there is one way enforcement (i.e. there is one point where the last SHA1 commit was signed by first SHA256 commit), I think it should be safe ?

The "commit before" might be compromised, but the git commits refer a snapshot of a tree + a list of previous commit IDs, so the "new" SHA256 commit will not have any files altered