Re: Verifiable git archives?

From: Andy Lutomirski <luto@amacapital.net>
Date: Jan 9, 2014, 22:50 UTC
Message-ID: <CALCETrWjHnpZxdsE3z_rZEUsNfdheDjSsZ2=yaxW8Hz4v05dLA@mail.gmail.com>
In-Reply-To: <xmqq38kwai3v.fsf@gitster.dls.corp.google.com>

On Thu, Jan 9, 2014 at 2:46 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 14 quoted lines

> Andy Lutomirski <luto@amacapital.net> writes:
>
>>> You only need the object name of the top-level tree.  After "untar"
>>> the archive into an empty directory, make it a new repository and
>>> "git add . && git write-tree"---the result should match the
>>> top-level tree the archive was supposed to contain.
>>
>> Hmm.  I didn't realize that there was enough metadata in the 'git
>> archive' output to reproduce the final tree.
>
> We do record the commit object name in the extended header when
> writing a tar archive already, but you have to grab the commit
> object from somewhere in order to read the top-level tree object
> name, which we do not record.

This could be changed :)

Show 5 quoted lines

>
> Also, if you used keyword substitution and such when creating an
> archive, then the filesystem entities resulting from expanding it
> would not match the original.
>

In the simple case, you'd need to have an archive with no prefix or funny business (or at least a known prefix). In the fancy case, you could at least verify that all the file contents really came from git, but then you'd really need the tree objects.

The use case I have in mind is for projects to distribute archives but only need to sign the tagged git commit id. I think this should be doable without too much pain. (This assumes that the release doesn't contain autogen output and such.)

--Andy