Hi, On Fri, 5 Mar 2010, Avery Pennarun wrote: > 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. If you find out which commit it was in the past, you can always revert it. It does not take Git to do it. I am all in favor of Git, yes, but let's be honest: Git does not prevent an intelligent break-in. To repeat, as I seem to not have made the point before: a break-in is a social problem, so it requires a social solution. Ciao, Dscho -- 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