Re: [PATCH v4] technical doc: add a design doc for hash function transition

[Jason Cooper <jason@lakedaemon.net>]

On Tue, Oct 03, 2017 at 02:40:26PM +0900, Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
...
> > +Meaning of signatures
> > +~~~~~~~~~~~~~~~~~~~~~
> > +The signed payload for signed commits and tags does not explicitly
> > +name the hash used to identify objects. If some day Git adopts a new
> > +hash function with the same length as the current SHA-1 (40
> > +hexadecimal digit) or NewHash (64 hexadecimal digit) objects then the
> > +intent behind the PGP signed payload in an object signature is
> > +unclear:
> > +
> > +	object e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7
> > +	type commit
> > +	tag v2.12.0
> > +	tagger Junio C Hamano <gitster@pobox.com> 1487962205 -0800
> > +
> > +	Git 2.12
> > +
> > +Does this mean Git v2.12.0 is the commit with sha1-name
> > +e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7 or the commit with
> > +new-40-digit-hash-name e7e07d5a4fcc2a203d9873968ad3e6bd4d7419d7?
> > +
> > +Fortunately NewHash and SHA-1 have different lengths. If Git starts
> > +using another hash with the same length to name objects, then it will
> > +need to change the format of signed payloads using that hash to
> > +address this issue.
> 
> This is not just signatures, is it?  The reference to parent commits
> and its tree in a commit object would also have ambiguity between
> SHA-1 and new-40-digit-hash.  And the "no mixed repository" rule
> resolved that for us---isn't that sufficient for the signed tag (or
> commit), too?  If such a signed-tag appears in a SHA-1 content of a
> tag, then the "object" reference is made with SHA-1.  If the tag is
> in NewHash40 content, "object" reference is made with NewHash40, no?

I do hope we adhere to "no mixed repository" rule.  Or, at least, "no
mixing of hash types".  Ambiguity opens cracks for uncertainty to creep
in.

For our case, where we counter-hash the sha1 commits, and counter-sign
the sha1-based signatures, we intend to include the relevant
sha1<->newhash lookups in the newhash signature body.  afaict, the git
sha1<->newhash table is not cryptographically secured underneath
signatures, and thus can't be used in the verification of objects.

The advantage to this approach is that we can be as explicit as
necessary with "SHA-1 -> SHA-512/256" or "SHA-1 -> SHA3-256" in the body
of the message.

thx,

Jason.