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

From: Jason Cooper <jason@lakedaemon.net>
Date: Oct 3, 2017, 13:08 UTC
Message-ID: <20171003130814.GJ31762@io.lakedaemon.net>
In-Reply-To: <xmqqbmlokcvp.fsf@gitster.mtv.corp.google.com>

On Tue, Oct 03, 2017 at 02:40:26PM +0900, Junio C Hamano wrote:

> Jonathan Nieder <jrnieder@gmail.com> writes:

...

Show 32 quoted lines

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