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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html