On Thu, Oct 20, 2011 at 03:13:56AM -0400, Jeff King wrote: > It's not that the commit is bad or the source of problems. My point is > that the assumption that commit messages are NUL-terminated has been > there for a really long time, so there are lots of spots in the code > that sloppily run string functions on them. Every one of those needs to > be found and fixed (e.g., I remember seeing this in > for-each-ref.c:find_subpos recently). Another possibility is to warn if the commit messages are not NULL terminated. 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. 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. That way, if anyone *does* figure out a way to generate real hash collisions with SHA1 of objects that look almost completely identical to the original objects, new implementations that would gradually make their way out to the field could verify the SHA-2 (or SHA-3, when it is announced, assuming that we the tag the checksums with a type identifier) checksums and notice that they are not correct. Maybe someone's already thought of this, but the cool thing about this idea is it's a way that we can upgrade to a stronger hash algorithm without needing a flag day due to some kind of incompatible format change; we keep using SHA1 for the user-visible hash, since it's fine modulo intentional attacks, and then use a hidden, backup checksum which can be checked either all the time, or if that turns out to be a computational burden, at some configurable random percent of the time. Anyway, just a thought.... - Ted -- 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