On Sat, Feb 28, 2015 at 09:48:05AM -0500, Colin Walters wrote:
>The above strawman code allows embedding the SHA256(git archive | tar).  Now,
>in order to make this work, the byte output of "git archive" must never change in the
>future.  I'm not sure how valid an assumption this is.  Timestamps are set to the
>commit timestamp, but I could imagine someone wanting to come along later
>and tweak the output to be compatible with some variant of tar or something.

This is not a safe assumption.  Unfortunately, kernel.org assumed that 
it was the case, and a change broke it.  Let's please not make more code 
that does that.

>We could define the checksum to be over the stream of raw objects, sorted by their checksum,
>and that way be independent of archiving format variations.

This would be a much better idea, assuming you mean "raw git objects". 
For cryptographic purposes, it's important to make the item boundaries 
unambiguous, which is usually done using the length.  Since the raw git 
objects include the length, this is sufficient.

If you don't make the boundaries unambiguous, you get the problem you 
have with v3 OpenPGP keys, where somebody could move bytes from one 
value to another, creating a different key, but with the same 
fingerprint (hash value).
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187