Re: weaning distributions off tarballs: extended verification of git tags

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Mar 5, 2015, 12:36 UTC
Message-ID: <54F84DCB.9000900@alum.mit.edu>
In-Reply-To: <xmqqsidn7ymg.fsf@gitster.dls.corp.google.com>

On 03/03/2015 12:44 AM, Junio C Hamano wrote:

Show 17 quoted lines

> [...]
> I was about to suggest another alternative.
> 
>     Pretend as if Git internally used SHA-512 (or whatever hash you
>     want to use) instead of SHA-1, compute the object names that
>     way.  Recompute the contents of a tree object is by replacing
>     the 20-byte SHA-1 field in it with a field with whatever
>     necessary length to hold the longer object names of elements in
>     the tree.
> 
> But then a realization hit me: what new value will be placed in the
> "parent " field in the commit object?  You cannot have SHA-512
> variant of commit object name without recomputing the whole history.
> 
> Now, if the final objective is to replace signature of tarballs,
> does it matter to cover the commit object, or is it sufficient to
> cover the tree contents?

The original goal was to replace a tarball signature, for which the "alternative" that you described above seems quite elegant.

If the goal were really to certify the entire history, then none of the proposals that I have seen so far is adequate anyway, because none of them propose to include better than the original SHA-1s of the parent commits.

Including other metadata from the release commit does not seem useful to me; how valuable is it to know the author and commit message of the last commit that happened to make it into a release? It would be more useful to know the SHA-1 of that commit, but that would presumably be included elsewhere in the packaging data used by the distribution.

> [...]

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu