On Thu, Oct 20, 2011 at 09:14:55AM -0400, Ted Ts'o wrote: > Another possibility is to warn if the commit messages are not NULL > terminated. A minor nit, but it's not whether they are terminated with NUL, but rather whether they have embedded NUL. But yeah, this could maybe just be something fsck looks for. > Note though that if we're really worried about a bad guy trying to > attack us with a hash collision, he/she could always use "invisible" > non-printing characters in the commit message, and/or just mess with > one or both of the timestamps. The more bits and more degrees of > flexibility the attacker has, the easier it would be, of course. In > the grand scheme of things it's not clear to me how big of a deal this > would be. Good point. Append-only attacks are cheaper, because you can avoid doing most of the hash computation on each iteration (like my patch does). But that's not a big-O speedup, it just makes the constant smaller. So you could assume that any feasible appending attack would probably become feasible for recomputing the full hash eventually. > If people were really concerned it would probably be easier to use > backup crypto checksum using something stronger (say, SHA-2 or the > eventual SHA-3). Just store the backup checksums of the parent > commitments in some backwardly compatible place that old git > implementations wouldn't look (say, after the NULL in the commit > message if there isn't a better place :-), and new implementations > would know to generate the checksums, and old implementations would > ignore it. Yeah, if birthday attacks against sha1 become possible, the sensible thing is probably not to worry too much about the file format, but to use a better hash. Commits can hide extra hashes in a header pretty easily. But what about trees and blobs? I don't think there's any "ignored" space in either one. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html