Re: RFC: Separate commit identification from Merkle hashing
- Date: Mon, 20 May 2019 22:38:32 -0400
- From: "Eric S. Raymond" <esr@xxxxxxxxxxx>
- Subject: Re: RFC: Separate commit identification from Merkle hashing
Jonathan Nieder <jrnieder@xxxxxxxxx>:
> 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,
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>