Re: Question about scm security holes

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 5, 2010, 22:33 UTC
Message-ID: <alpine.DEB.1.00.1003052331140.20986@pacific.mpi-cbg.de>
In-Reply-To: <32541b131003051022oe64428bsa387e64e30bbeaab@mail.gmail.com>

Hi,

On Fri, 5 Mar 2010, Avery Pennarun wrote:

Show 16 quoted lines

> 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.

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