Re: Verifiable git archives?

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

 



Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:

> On 01/09/2014 09:11 PM, Junio C Hamano wrote:
>> Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes:
>> 
>>> It's possible, in principle, to shove enough metadata into the output
>>> of 'git archive' to allow anyone to verify (without cloning the repo)
>>> to verify that the archive is a correct copy of a given commit.  Would
>>> this be considered a useful feature?
>>>
>>> Presumably there would be a 'git untar' command that would report
>>> failure if it fails to verify the archive contents.
>>>
>>> This could be as simple as including copies of the commit object and
>>> all relevant tree objects and checking all of the hashes when
>>> untarring.
>> 
>> 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.
>> [...]
>
> This wouldn't work if any files were excluded from the archive using
> gitattribute "export-ignore" (or "export-subst", which you already
> mentioned in a follow-up email).

Correct.  By "and such" below, I meant any and all futzing that
makes the resulting working tree different from the tree object
being archived ;-)  That includes the line-ending configuration
and other things as well.

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