On Fri, Sep 09, 2011 at 12:03:01PM -0400, Joey Hess wrote: > The most credible attack I have so far does not involve binary files in > tree. Someone pointed out that git log, git show, etc stop printing > commit messages at NULL. It was me. > It might be worth ameloriating that attack by making git log always > show the full buffer. Or it would be easy to write a tool that finds > any commits that have a NULL in their message. Unfortunately, that is going to involve a pretty huge code audit of git, as the "tack a \0 to the end of an object just in case" code dates back quite a while (e871b64, unpack_sha1_file: zero-pad the unpacked object, 2005-05-25). So I suspect there is a lot of code built on top of the assumption that commit messages are NUL-terminated strings. Besides which, that is only one form of hiding. If collision attacks against sha1 become a possibility, I think we are better to talk about moving to a new hash. Even sha-256 truncated to 160 bits would be better than sha-1 (AFAIK, that family of SHA does not suffer from the same attacks, so we would still be in the 2^80 range for collision attacks). -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