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
Attachment:
signature.asc
Description: Digital signature