Re: Question about scm security holes

From: Avery Pennarun <apenwarr@gmail.com>
Date: Mar 5, 2010, 18:22 UTC
Message-ID: <32541b131003051022oe64428bsa387e64e30bbeaab@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.1003050953580.20986@pacific.mpi-cbg.de>

On Fri, Mar 5, 2010 at 4:25 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 10 quoted lines

> 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