Re: The future of commit access policy for core Firefox

Am 09.03.17 um 22:53 schrieb Mike Connor:
> (please direct followups to dev-planning, cross-posting to governance,
> firefox-dev, dev-platform)
> 
> 
> Nearly 19 years after the creation of the Mozilla Project, commit access
> remains essentially the same as it has always been.  We've evolved the
> vouching process a number of times, CVS has long since been replaced by
> Mercurial & others, and we've taken some positive steps in terms of
> securing the commit process.  And yet we've never touched the core idea of
> granting developers direct commit access to our most important
> repositories.  After a large number of discussions since taking ownership
> over commit policy, I believe it is time for Mozilla to change that
> practice.
> 
> Before I get into the meat of the current proposal, I would like to outline
> a set of key goals for any change we make.  These goals have been informed
> by a set of stakeholders from across the project including the engineering,
> security, release and QA teams.  It's inevitable that any significant
> change will disrupt longstanding workflows.  As a result, it is critical
> that we are all aligned on the goals of the change.
> 
> 
> I've identified the following goals as critical for a responsible commit
> access policy:
> 
> 
>     - Compromising a single individual's credentials must not be sufficient
>     to land malicious code into our products.
>     - Two-factor auth must be a requirement for all users approving or
>     pushing a change.
>     - The change that gets pushed must be the same change that was approved.
>     - Broken commits must be rejected automatically as a part of the commit
>     process.

<--->

> I know this is a major change in practice from how we currently operate,
> and my ask is that we work together to understand the impact and concerns.
> If you find yourself disagreeing with the goals, let's have that discussion
> instead of arguing about the solution.  If you agree with the goals, but
> not the solution, I'd love to hear alternative ideas for how we can achieve
> the outcomes outlined above.
> 

Hi,

I actually have issues with the goals, so I cut out the impl parts.

Here's goals that I'd add to be explicitly stated:

- We want as many people as possible to change the Firefox code base.
- We want to be able to change the Firefox code base going to release 
audience as quickly as possible.

How those goals or technical decisions work in favor of goals is really 
hard to evaluate without some threat models.

Also, you've been vague on which repositories you intend to cover, and I 
also think that that depends on the threat models.

So, along the lines of David's ask in .platform, I'd really appreciate 
to get more details on the problems we're hoping to mitigate.

Axel