Re: Question about scm security holes

From: Avery Pennarun <apenwarr@gmail.com>
Date: Mar 5, 2010, 03:28 UTC
Message-ID: <32541b131003041928m50aee3d0jcde58f3f4ff63a8b@mail.gmail.com>
In-Reply-To: <4B907884.5080501@gmail.com>

On Thu, Mar 4, 2010 at 10:20 PM, walt <w41ter@gmail.com> wrote:

Show 10 quoted lines

> On 03/04/2010 06:03 PM, Avery Pennarun wrote:
>> ...you can create a commit with
>> whatever committer/author names you want and then push them in.
>> Commits aren't GPG-signed, only tags are, so there are lots of ways to
>> forge a commit from someone else and mess up the audit log...
>
> Thanks, that's the kind of reply I was hoping for.  Do you think there
> should be a way to sign the commits themselves, at least as an option?
>
> I certainly wouldn't bother, but OTOH nobody wants to steal my code :-/

The whole thing is a bit overblown. One of my friends once took me on a tour of Microsoft on a weekend. The place was mostly deserted, but tons of developers left their workstations unlocked overnight, and everyone had a private office. And with tens of thousands of developers on the campus, nobody would know if you're supposed to be there or not.

It would have been easy to walk off with the source code to Windows from one of those workstations. The fact is, nobody really *wants* the source code to Windows, except probably to look at it and be horrified.

What would you do if you stole the source code to Adobe's flash player? It's illegal (in the U.S. anyway) to reverse engineer it and it's illegal to steal it, so you're on the wrong side of the law no matter how you pretend you managed to figure out a way around their DRM or whatever.

People describe source code as a company's "crown jewels," but that's a bit of a joke. I can barely get our interns to figure out how to compile and understand our code. Expecting a thief to do it, with nothing but a raw repo and hundreds of gigabytes of crap, is pure paranoia.

Sneaking in patches? Yeah, watch out for that. But you should be reviewing patch changelogs anyway. At least git prevents people from *retroactively* changing stuff; they can only add patches on top, so it's easy to review after a break-in.

Have fun,

Avery