Web lists-archives.com

Re: RFC: Another proposed hash function transition plan




On 03/06/2017 12:43 AM, Jeff King wrote:
Overall the basics of the conversion seem sound to me. The "nohash"
things seems more complicated than I think it ought to be, which
probably just means I'm missing something.  I left a few related
comments on the google doc, so I won't repeat them here.

I think "nohash" can be explained in 2 points:
 1. When creating signed objects, "nohash" is almost never written. Just
    create the object as usual and add "hash" lines for every other hash
    function that you want the signature to cover.
 2. When converting from function A to function B, add "nohash B" if
    there were no "hash B" lines in the original object.

The "nohash" thing was in the hope of requiring only one signature to sign all the hashes (in all the functions) that the user wants, while preserving round-tripping ability.

Maybe some examples would help to address the apparent complexity. These examples are the same as those in the document. I'll also show future compatibility with a hypothetical NEW hash function, and extend the rule about signing/verification to 'sign in the earliest supported hash function in ({object's hash function} + {functions in "hash" lines} - {function in "nohash" line})'.

Example 1 (existing signed commit)
<sha-1 object stuff>  <sha256 object stuff>  <NEW object stuff>
                      nohash sha256          nohash new
                      hash sha1 ...          hash sha1 ...

This object was probably created in a SHA-1 repository with no knowledge that we were going to transition to SHA256 (but there is nothing preventing us from creating the middle or right object and then translating it to the other functions).

Example 2 (recommended way to sign a commit in a SHA256 repo)
<sha-1 object stuff>  <sha256 object stuff>  <NEW object stuff>
hash sha256 ...       hash sha1 ...          nohash new
                                             hash sha1 ...
                                             hash sha256 ...

This is the recommended way to create a SHA256 object in a SHA256 repo. The rule about signing/verification (as stated above) is to sign in SHA-1, so when signing or verifying, we convert the object to SHA-1 and use that as the payload. Note that the signature covers both the SHA-1 and SHA256 hashes, and that existing Git implementations can verify the signature.

Example 3 (a signer that does not care about SHA-1 anymore)
<sha-1 object stuff>  <sha256 object stuff>  <NEW object stuff>
nohash sha1                                  nohash new
hash sha256 ...                              hash sha256 ...

If we were to create a SHA256 object without any mentions of SHA-1, the rule about signing/verification (as stated above) states that the signature payload is the SHA256 object. This means that existing Git implementations cannot verify the signature, but we can still round-trip to SHA-1 and back without losing any information (as far as I can tell).