Re: RFC: Separate commit identification from Merkle hashing

From: Jonathan Nieder <jrnieder@gmail.com>
Date: May 21, 2019, 02:58 UTC
Message-ID: <20190521025813.GA175422@google.com>
In-Reply-To: <20190521023832.GA130381@thyrsus.com>

Hi,

Eric S. Raymond wrote:

> Jonathan Nieder <jrnieder@gmail.com>:
>> 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.

[...]

Show 7 quoted lines

>> 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...

Take your time. :)

[...]

> 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.)

Hm, can you point to what part of the doc suggested that? Best to make the text clearer, to avoid confusing the next person.

On the contrary, the design is very careful to be able to support the next transition.

[...]

>                                    The same technique (probably the
> same code!) could be used to map the otherwise uninterpreted
> commit-IDs I'm proposing to lookup keys.

No, since Git relies on commit IDs for integrity checking. The hash function transition described in that document relies on round-tripping ability for the duration of the transition.

Jonathan