Re: The future of commit access policy for core Firefox

On 3/12/17 8:44 PM, Daniel Veditz wrote:
> This does add overhead when applied to developers who are, in fact,
> trusted. On the surface, clearly noted in this thread, that seems
> insane. But at the top of this thread, the worry was "what if a trusted
> committer's credentials get compromised?" Currently the answer is "We're
> screwed". We can hope the sheriffs would notice an odd patch during
> uplift, but the sheriffs are busy and any attacker who was any good
> would make sure the patch looked totally normal on the surface.

I feel like there's an important point to be made here.  If I had 
compromised a developer's credentials and were trying to get an attack 
past a "review right before landing" system, I would do it as follows:

1)  In one patch, introduce some code that relies on an invariant that 
currently holds.

2)  In another, non-conflicting, patch, introduce a violation of that 
invariant and fix up the other places depending on it, but not the one 
from item 1.

3)  Have different people review the two patches.

4)  Make sure I have both reviews before landing either patch, so the 
reviewers can't catch the problem.  There are various ways of doing 
this, like making both patches depend on yet at third patch that I make 
sure gets reviewed slowly.

This is a somewhat higher bar than just "add the malicious code and land 
it", of course.  But this is also what I came up with after about 30 
seconds' worth of thought...

-Boris