Re: Verifiable git archives?

Michael Haggerty [off-list ref] writes:

On 01/09/2014 09:11 PM, Junio C Hamano wrote:

quoted

Andy Lutomirski [off-list ref] writes:

quoted

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.

Here's a rather hackish implementation of the write side.  Any
thoughts on the format?  (Obviously the implementation needs work.
For example, it needs to be optional.

Thoughts so far:
 - I want to put the value of "prefix" into an extended header.
 - Should blobs have their sha1 hashes in an extended header?  Pros:
it makes figuring out substitutions easier.  Cons: it adds 512 bytes
per file.
 - I want to support tags as roots.
 - I (or someone) need to write a verifier / verified unpacker.  Does
git accept Python code?

This thing is tested in the sense that GNU tar unpacks its output
without any warnings or other fanfare.

--Andy