verifying git file contents without checking out history?

verifying git file contents without checking out history?

[Marc Weber]

git clone --depth=20 $url; git checkout $hash

How to verify that I have the contents I think I have - given that I
trust my local git executable?

Would it be enough to also store the git log --pretty=format:%T $hash
value and check that only? %T is the root tree hash.

Does git checkout verify the file tree checksum when receiving all blob
objects from a server?
Then verifying that %T didn't change should be enough to enable me
fetching sources and trust them without running git fsck which would
fetch all history.

Marc Weber

Re: verifying git file contents without checking out history?

[Junio C Hamano]

Marc Weber <marco-oweber@gmx.de> writes:

> git clone --depth=20 $url; git checkout $hash
>
> How to verify that I have the contents I think I have - given that I
> trust my local git executable?

Define what you mean by "contents".  Do you care only about the tree
state recorded in that $hash, and you also trust that $hash is the
correct one?

  $ git cat-object commit $hash | git hash-object --stdin -t commit

would be a way to verify that you do have the commit object
everybody else calls $hash, and you can verify the objects contained
within the commit whose name is $hash (i.e. its tree and its
parents) in a similar way.  Use "git ls-tree $tree" to find out the
objects your top-level tree recorded in the commit $hash, and you
can verify the contents recorded in the tree object recursively.

Re: verifying git file contents without checking out history?

[Marc Weber]

Excerpts from Junio C Hamano's message of Mon Nov 19 05:55:18 +0100 2012:
> Define what you mean by "contents".
contents = the files git archive HEAD would put into an archive, those
determining a build result.

How could the repo be compromised:
1) An attacker triest to find a hash collision in the HEAD tree.
  However finding a hash collision which also is a useful attack should
  be very hard.

2) The attacker modifies a file the way he likes (thus the attack is
  easy), then he tries to modify the history in a way causing the same 
  commit hash.
  Probably this is very hard, too.

Does this make sense? I feared that having a HEAD^ you can manipulate to
change the hash of HEAD makes it easier to cause a collision without the
user noticing. 
However adding additional useless files to HEAD could be used to cause a
imaginary hash collision, too. Thus having a second hash would not be of
any benefit. Thus referring to commit by hash (using all hash digits) is
best you can do. I finally got it.

Thanks
Marc Weber