Re: verifying git file contents without checking out history?

From: Marc Weber <marco-oweber@gmx.de>
Date: Nov 19, 2012, 05:32 UTC
Message-ID: <1353303050-sup-4193@nixos>
In-Reply-To: <7vtxsmxkcp.fsf@alter.siamese.dyndns.org>

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