Re: RFC: Separate commit identification from Merkle hashing

From: Eric S. Raymond <esr@thyrsus.com>
Date: May 21, 2019, 02:38 UTC
Message-ID: <20190521023832.GA130381@thyrsus.com>
In-Reply-To: <20190521015703.GB32230@google.com>

Jonathan Nieder <jrnieder@gmail.com>:

Show 15 quoted lines

> Hi!
> 
> Eric S. Raymond wrote:
> 
> > One reason I am sure of this is the SHA-1 to whatever transition.
> > We can't count on the successor hash to survive attack forever.
> > Accordingly, git's design needs to be stable against the possibility
> > of having to accommodate multiple future hash algorithms in the
> > future.
> 
> Have you read through Documentation/technical/hash-function-transition?  It
> takes the case where the new hash function is found to be weak into account.
> 
> Hope that helps,
> Jonathan

Reading now...

At first sight I think it looks pretty compatible with what I am proposing. The goals anyway, some of the implementation tactics would change a bit.

I think it's a weakness, though, that most of it is written as though it assumes only one hash transition will be necessary. (This is me thinking on long timescales again.)

Instead of having a gpgsig-sha256 field, I would change the code so all hash cookies have an delimited optional prefix giving the hash-algorithm type, with an absent prefix interpreted as SHA-1.

I think the idea of mapping future hashes to SHA-1s, which are then used as fs lookup keys, is sound. The same technique (probably the same code!) could be used to map the otherwise uninterpreted commit-IDs I'm proposing to lookup keys.

I should have said in my previous mail that I'm prepared to put my coding fingers into making all this happen. I am pretty sure my gramty manager will approve.

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>