Re: [RFC] Malicously tampering git metadata?

[Jeff King <peff@peff.net>]

On Tue, Dec 15, 2015 at 10:26:39PM -0500, Santiago Torres wrote:

> An example of a malicious commit merge follows:
> 
> 1) The attacker controlling or acting as the upstream server identifies
> two branches: one in which the unsuspecting developer is working on, and
> another in which a vulnerable piece of code is located.

One thing to make clear here: the side branch with the vulnerable code
must be a _new_ vulnerability that was not already part of the "main"
branch the developer is working on. That is, I do not immediately see a
way to resurrect an old vulnerability, because a merge of the old,
broken commit would not result in reintroducing it.

This is more about "there was experimental junk on branch X, and you
tricked some developer into pulling X onto Y, and now Y unexpectedly has
the junk on it". And I agree with Stefan that push-certs are the
intended defense against this.

Of course, in the real world things are much easier. Most projects do
not sign commits at all, let alone use push certs. If developers are
pulling from a compromised server, then you can simply make up whatever
broken commits you want, and there's no way to tell the difference
between them and the real commits.

-Peff