Re: Question about scm security holes

[Avery Pennarun <apenwarr@gmail.com>]

On Fri, Mar 5, 2010 at 4:25 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> 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