Jonathan Nieder <jrnieder@xxxxxxxxx>: > 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>
