Re: The future of commit access policy for core Firefox

On 3/9/17 4:53 PM, Mike Connor wrote:
>    - Compromising a single individual's credentials must not be sufficient
>    to land malicious code into our products.

This is a good goal in general.  Devil is in the details, of course...

>    - Two-factor auth must be a requirement for all users approving or
>    pushing a change.

This seems reasonable if we're willing to help contributors with this 
(e.g. hand out yubikeys as needed).

>    - The change that gets pushed must be the same change that was approved.

This sounds great at first glance, but I suspect is hellish in practice, 
as others have pointed out in the thread.  Given the need to rebase, 
this is completely impossible to achieve as stated.  We should figure 
out what the _real_ goal is here.  It's possible it's actually more than 
one goal.

>    - Broken commits must be rejected automatically as a part of the commit
>    process.

This looks good.

I think there are some critical goals missing.  Some of these may be 
something we're assuming everyone shares as a goal, but I'd rather make 
them explicit, because I think some of these are not in fact being 
considered in the specific changes being proposed.  I think some of 
these are more contentious than others....

- Pushing is possible.
- Pushing is possible for non-MoCo-employees.
- Pushing is not a serious time drain on the patch author.  The term
   "serious" needs definition.
- Pushing is not a serious time drain on the patch reviewer.  The
   term "serious" needs definition.
- There should be little incentive to do one push instead of
   multiple pushes for work that is conceptually separate.

I may be missing some, honestly.  I have tried to think about edge cases 
here, but having a failure of imagination.

We should have a clear concept of workflows that we consider "in scope" 
for this system in terms of evaluating the "not a time drain" goals.  I 
have explicitly not put any specific workflows in my list of critical 
goals, though I consider some workflows critical.  I mean workflows in 
terms of how work is organized into commits/pushes/bugs, not workflows 
like branch-based vs mq vs git vs hg vs whatever.  As a concrete 
example, pushing multiple things that depend on each other in practice 
but not conceptually should probably not be considered an edge case. 
That is, I'm talking about changes to the same code (hence need to be 
pushed in the right order) but belonging to separate bugs and needing to 
be tracked separately and whatnot. [1]

Basically, the current set of goals is more or less all defined from a 
security perspective, and seems to be treating usability as a non-goal. 
I think approaching the problem from that perspective will create an 
unusable system [2], and we need to have specific usability goals in 
mind as we design this.  The above are my suggestions for high-level 
usability goals, but I would like to see what suggestions others have.

I am explicitly not writing down specific proposals that I think would 
help achieve the "not a serious time drain" goals, but I do have some 
thoughts here and am happy to drill down into them if we agree on those 
goals in general.

-Boris

[1] The current mozreview+autoland workflow falls down badly on this, 
for example.  See https://bugzilla.mozilla.org/show_bug.cgi?id=1344432

[2] Citation needed, but I think this is a commonly understood thing 
about software security.  Examples like encrypted email, our old sync 
service, etc abound.  And those are examples where people _were_ 
considering usability!