On Fri, Mar 5, 2010 at 4:25 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > The trick now is to craft the commit in such a manner that it will not be > noticed retro-actively. This is a simple case of social engineering: you > have to imitate the style of the committer/author you are impersonating. > The commit message must look like the usual ones (typos, preferred words, > grammar, length of paragraphs, comprehensibility, etc) > > Likewise, the code has to be analyzed for style, and obviously for most > likely targets of a backdoor (both in terms of "it is a perfect spot for > a backdoor" and "it is not uncommon for the author to touch that > part of the code"). There is still one major advantage to preventing modification of past commits: once you find out there's been a breach, you can just go back through the commits *since* the breach and double-check them. Without that guarantee, you have to recheck *every* commit, which is much more work. Not to say that a sneaky commit would be easy to detect, though. I often add bugs to my own code without even trying to hide them, and they're still pretty hard to find afterward. Have fun, Avery -- 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