Commit Access Policy - draft for comment
Gervase Markham
all absolutely fine. But just in case it's not, here's a repost
including .planning to try and attract more comment. I wouldn't want
people to feel blindsided. If you know people who might want to comment
on this and you think they won't have seen it, please tell them.]
"Currently, Mozilla has a large number of code trees in various source
code management systems, many of which have differing requirements for
access. This is confusing and difficult for both developers and
administrators. This document is the first draft of a vision for what a
unified commit access policy might look like. Having a clear commit
access policy makes the lives of developers and administrators alike
easier."
https://wiki.mozilla.org/Commit_Policy
This is likely to need careful review and improvement; I've been working
on this for a while now but I'm still sure I haven't got it right first
time. Comments welcome in mozilla.governance.
Gerv
Axel Hecht
FYI, I still have that policy in a tab, but I didn't get to reading it yet.
Axel
Bradley Baetz
Is this meant to apply to non-'core' mozilla bits hosted by mozilla.org?
(i.e. bugzilla, tinderbox, etc?)
If so, I have a few comments:
1. For 'level 2', remove mentions of specific VCSs - some of the above
is still in CVS (and possibly moving to bzr at some point)
2. Not sure if 'level 1' access should be implied for those users - not
really much use with the parent program in CVS, although it probably
doesn't hurt.
3. Re note 1, CVS for those projects isn't going to go away by the end
of next month, although despot does split off webtools from everything else.
Bradley
Bradley Baetz
Is this meant to apply to non-'core' mozilla bits hosted by mozilla.org?
Mike Connor
-- Mike
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Benjamin Smedberg
> https://wiki.mozilla.org/Commit_Policy
Level 2 is still not clear to me.
If I vouch for someone to have access to the electrolysis project
repository, does that mean they would automatically have access to all the
other "level 2 repositories" (or at least the others which are hosted in
hg?) Or would each project repository have its own LDAP permissions group?
For level 3, what does "comprehensive review" mean? Currently the
electrolysis tree is not locked down (hg_mozsrc), so that some external
contributors who only work on e10s can push to it. This code is destined to
eventually become part of mozilla-central: most of it is being reviewed as
we push to e10s, but we will certainly have to do additional review before
merging in with mozilla-central. Does this mean that the additional
contributors would have to get level 3 access? I hope not: one of the points
of the project repository was to be able to bring in additional contributors
more easily without blocking work on the main trees. We are watching the
pushlog and reading commits carefully, so I don't think there is a danger
inherent in the current system.
--BDS
Gervase Markham
> Is this meant to apply to non-'core' mozilla bits hosted by mozilla.org?
> (i.e. bugzilla, tinderbox, etc?)
Yes.
> If so, I have a few comments:
>
> 1. For 'level 2', remove mentions of specific VCSs - some of the above
> is still in CVS (and possibly moving to bzr at some point)
I've altered the list to make it clear that it's the software that's
primary and the VCS used is secondary. But I think it's useful to note
which VCS it is.
> 2. Not sure if 'level 1' access should be implied for those users - not
> really much use with the parent program in CVS, although it probably
> doesn't hurt.
Level 1 access only really makes sense for Hg. Under the proposed
technical arrangements, it's not possible to give them Level 2 access to
something without giving them Level 1 access.
> 3. Re note 1, CVS for those projects isn't going to go away by the end
> of next month, although despot does split off webtools from everything
> else.
That note specifically refers to Level 3 (core product) access, and so
isn't aimed at webtools.
Thanks for your feedback!
Gerv
Gervase Markham
> Level 2 is still not clear to me.
>
> If I vouch for someone to have access to the electrolysis project
> repository, does that mean they would automatically have access to all the
> other "level 2 repositories" (or at least the others which are hosted in
> hg?)
Yes, all the ones which are hosted in Hg.
This is proposed because my understanding is that setting up a
permissions bit for every repository, and managing that, would be
administratively very onerous.
The person you vouch for would not have the ability to directly affect
core product code (that requires level 3). And socially, they would be
expected to only check in to trees whose owners had asked them to check
in to. But yes, we are proposing to enforce that separation socially
rather than technically.
Do you think it needs to be enforced technically?
If there are people who you want to give access to but do not trust
sufficiently, would making electrolysis an incubator project (i.e. at
level 1) help?
> For level 3, what does "comprehensive review" mean? Currently the
> electrolysis tree is not locked down (hg_mozsrc), so that some external
> contributors who only work on e10s can push to it. This code is destined to
> eventually become part of mozilla-central: most of it is being reviewed as
> we push to e10s, but we will certainly have to do additional review before
> merging in with mozilla-central. Does this mean that the additional
> contributors would have to get level 3 access? I hope not: one of the points
> of the project repository was to be able to bring in additional contributors
> more easily without blocking work on the main trees. We are watching the
> pushlog and reading commits carefully, so I don't think there is a danger
> inherent in the current system.
The goal of this "comprehensive review at merge time" section is that
code which gets into the core product trees should have been reviewed,
in the form in which it is merged into those trees, by someone with
level 3 access. In other words, it's an attempt to draw the boundaries
around the core product code, and require level 3 access or review for
code to cross them. I'm entirely open to the idea that the current
wording may not be the best way of achieving this.
Do you think this is a reasonable thing? If so, how would you do it?
Gerv
Benjamin Smedberg
> Do you think it needs to be enforced technically?
Not really, but I don't understand why we need the distinction between Level
1 and 2... what class of people would we trust enough to give level 1 (which
comes with the ability to screw up the tryserver), but not trust enough to
give access to various project repositories?
>> For level 3, what does "comprehensive review" mean? Currently the
>> electrolysis tree is not locked down (hg_mozsrc), so that some external
>> contributors who only work on e10s can push to it. This code is destined to
>> eventually become part of mozilla-central: most of it is being reviewed as
>> we push to e10s, but we will certainly have to do additional review before
>> merging in with mozilla-central. Does this mean that the additional
>> contributors would have to get level 3 access? I hope not: one of the points
>> of the project repository was to be able to bring in additional contributors
>> more easily without blocking work on the main trees. We are watching the
>> pushlog and reading commits carefully, so I don't think there is a danger
>> inherent in the current system.
>
> The goal of this "comprehensive review at merge time" section is that
> code which gets into the core product trees should have been reviewed,
> in the form in which it is merged into those trees, by someone with
> level 3 access. In other words, it's an attempt to draw the boundaries
> around the core product code, and require level 3 access or review for
> code to cross them. I'm entirely open to the idea that the current
> wording may not be the best way of achieving this.
>
> Do you think this is a reasonable thing? If so, how would you do it?
I think it conflates review and push requirements in a strange way. I want
this sequence to work:
* Electrolysis works on a review-as-you-go system.
* I trust Fred (a contractor) to push good stuff to Electrolysis, but he
doesn't need access to mozilla-central and since he hasn't worked outside of
e10s it's unlikely I'd find vouchers outside of e10s.
* At some point, we'll merge e10s into mozilla-central.
It would seem, according to these rules, that we'd either have to re-review
all the e10s changes when we merge into m-c, which is impractical given the
size, or we'd have to get Fred level 3 access.
It seems to me that the core difference between level 3 and the others is
that with Level 3 access you can break the most important trees and delay
hundreds of developers. If Fred (or any of us) break e10s, we only affect
5-10 people or so, and the tree rules are more lenient for exactly this
reason. We leave trees broken overnight, or particular trees orange for a
week, or whatever. The level of trust required that somebody won't break m-c
(and will clean up messes promptly, stay on IRC, etc) is much higher.
--BDS
Gervase Markham
> Not really, but I don't understand why we need the distinction between
> Level 1 and 2... what class of people would we trust enough to give
> level 1 (which comes with the ability to screw up the tryserver), but
> not trust enough to give access to various project repositories?
My understanding was that the tryserver in particular is designed to be
secure and unscrewuppable. BICBW.
Is your proposal that we have only two levels of access - core product
code (one binary permission) and everything else (one binary permission)?
> It seems to me that the core difference between level 3 and the others
> is that with Level 3 access you can break the most important trees and
> delay hundreds of developers. If Fred (or any of us) break e10s, we only
> affect 5-10 people or so, and the tree rules are more lenient for
> exactly this reason. We leave trees broken overnight, or particular
> trees orange for a week, or whatever. The level of trust required that
> somebody won't break m-c (and will clean up messes promptly, stay on
> IRC, etc) is much higher.
OK. So your point is that the idea of a distinction between levels 2 and
3 is valid, but the category for a tree being in level 3 should relate
solely to its importance to the project, and not to any level of
"security" we need to have around checkins to code in those trees?
Gerv
Benjamin Smedberg
> My understanding was that the tryserver in particular is designed to be
> secure and unscrewuppable. BICBW.
It's much better than it used to be, but there's certainly risk there,
especially if somebody is being intentionally malicious.
> Is your proposal that we have only two levels of access - core product
> code (one binary permission) and everything else (one binary permission)?
Yes, though I'm happy to hear reasons why the middle level is needed.
>> It seems to me that the core difference between level 3 and the others
>> is that with Level 3 access you can break the most important trees and
>> delay hundreds of developers. If Fred (or any of us) break e10s, we only
>> affect 5-10 people or so, and the tree rules are more lenient for
>> exactly this reason. We leave trees broken overnight, or particular
>> trees orange for a week, or whatever. The level of trust required that
>> somebody won't break m-c (and will clean up messes promptly, stay on
>> IRC, etc) is much higher.
>
> OK. So your point is that the idea of a distinction between levels 2 and
> 3 is valid, but the category for a tree being in level 3 should relate
> solely to its importance to the project, and not to any level of
> "security" we need to have around checkins to code in those trees?
Yes.
--BDS
Mike Shaver
> My understanding was that the tryserver in particular is designed to be
> secure and unscrewuppable. BICBW.
If that were the case it would not require any authentication. I wish
it were (and think it can be made so if we want to spend a bit of
time) but it is not currently, alas.
Mike
Gervase Markham
>> My understanding was that the tryserver in particular is designed to be
>> secure and unscrewuppable. BICBW.
>
> It's much better than it used to be, but there's certainly risk there,
> especially if somebody is being intentionally malicious.
What is the nature of the risk? A risk of DOS (try server dies)? Or a
risk of Mozilla internal network compromise?
Presumably someone who killed the try server in a way that even vaguely
looked intentional would have their credentials pulled, the server would
be rebooted, the person who vouched for their level 1 access would
shuffle their feet in an embarrassed fashion, and we'd all get on with life?
>> Is your proposal that we have only two levels of access - core product
>> code (one binary permission) and everything else (one binary permission)?
>
> Yes, though I'm happy to hear reasons why the middle level is needed.
Here's another way of thinking about the levels:
Level 1: a single Mozilla project contributor wants you to collaborate
with them on a personal project, or you are a new and not-well-known
contributor who wants to use the try servers.
Level 2: a Mozilla module owner knows and trusts you enough to give you
checkin rights to their module
(or, if we radically simplify level 2 and make it a single bit giving
access to "everything that's not level 3": a Mozilla module owner wants
you to help with something and is willing to take responsibility if you
mess up someone else's tree)
Level 3: you are well known to us, and considered competent to write to
important repositories
I'm not sure we could merge levels 1 and 2 without either raising the
bar for getting access (which would inhibit collaboration) or increasing
the risk of malicious action from a mostly-unknown person.
Of course, one might argue that the try servers need to be in level 2
rather than level 1 for technical safety reasons. Although that would be
a shame.
Thanks for taking the time to help me think this through, BTW. Just
because I'm defending it doesn't mean I'm set on the current plan!
Gerv
Robert Kaiser
> On 03/12/09 15:00, Benjamin Smedberg wrote:
>>> My understanding was that the tryserver in particular is designed to be
>>> secure and unscrewuppable. BICBW.
>>
>> It's much better than it used to be, but there's certainly risk there,
>> especially if somebody is being intentionally malicious.
>
> What is the nature of the risk? A risk of DOS (try server dies)? Or a
> risk of Mozilla internal network compromise?
Well, someone pushing anything to try makes our try machines at least
compile and execute the code, and upload it to some public place on the
FTP server - all of those stages can for sure be exploited by malicious
code being posted to the try system - but at the same time all those
things are what we want to be done with benevolent code being put there.
A second level more unknown to me as it depends on the specific setup is
what the try machines have access to when executing complie instructions
and compiled code, inlcuding the areas on stage they can write to
(including potential overwriting of files more people are fetching) -
all of which should ideally be reduced to as little as possible, but not
sure what exploit vectors there still would be.
I'm not saying we would be like to give any permission to push anything
to any commit level to someone malicious, but lowering the entry
barriers too much there may improve the (probably always exisitng)
chance of someone able to sneak in by looking mostly harmless but acting
bad in the end, due to whatever reason.
Robert Kaiser
Gervase Markham
> Well, someone pushing anything to try makes our try machines at least
> compile and execute the code, and upload it to some public place on the
> FTP server - all of those stages can for sure be exploited by malicious
> code being posted to the try system - but at the same time all those
> things are what we want to be done with benevolent code being put there.
Sure.
My assumption was that the try servers were implemented as something
like checkpointed VMs which were rolled back after every build, so that
malicious code was just eliminated. I guess I was wrong about that.
But I agree, having builds on our FTP servers with malicious code in
isn't great, even if they never get pushed to an update channel and
people have to download and install them manually.
> I'm not saying we would be like to give any permission to push anything
> to any commit level to someone malicious, but lowering the entry
> barriers too much there may improve the (probably always exisitng)
> chance of someone able to sneak in by looking mostly harmless but acting
> bad in the end, due to whatever reason.
So what's the counter-proposal? That the try servers be at level 2
rather than level 1?
Gerv