Re: Verifiable git archives?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 9, 2014 at 2:46 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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 :)

>
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]