Commit Access Policy: issue of production websites
Gervase Markham
https://wiki.mozilla.org/Commit_Access_Policy
However, there is a problem which might require a further change. We
need to resolve it quickly because IT are in the middle of implementing
the technical changes for the current policy.
It has been pointed out that treating SVN as one large repository at
"level 2" means that a large number of people will suddenly gain access
to check into the code repositories for our production websites such as
www.mozilla.com, www.mozilla.org, getfirebug.com and the Planets. Code
from some production websites, including those named above, is pulled
into production by an automated script on a regular schedule.
So if someone were to, say, check in a change deleting the entirety of
www.mozilla.com and it were not noticed, then the website would go down
20 minutes later. Or they could delete every site in SVN at once.
The set of people currently trusted to check in to these websites does
not significantly overlap with the set trusted to check in to the code
repositories.
We have a number of options:
1) Do nothing, and rely on social controls.
2) Forbid the auto-updating of websites; say that it has to be done
manually.
3) Put those sites at Level 3 instead of 2 (but this would require
another set of entry criteria for Level 3, and the overlap in
personnel is not great)
4) Create two Level 3s - Level 3 (websites) and Level 3 (code). This
would require technical changes, hence my desire to work out what we
want to do quickly.
Thoughts?
Gerv
davidwboswell
> https://wiki.mozilla.org/Commit_Access_Policy
If this is finalized can you tell me how you'd like to link to this
from the Policies page (and if you notice any other policies missing
from this list, let me know).
http://www.mozilla.org/about/policies/
Are you also thinking of keeping the policy on the wiki or were you
just editing it there? From earlier discussions about policies
several people felt that having policies on a wiki conveyed an image
of the document being a draft and incomplete even if this wasn't the
case.
> 2) Forbid the auto-updating of websites; say that it has to be done manually.
If possible I'd like to avoid this option since mozilla.org has a wide
range of committers that don't coordinate on changes so a push to
production model isn't ideal.
David
Mike Connor
On 2010-02-25, at 9:03 AM, Gervase Markham wrote:
> We have a number of options:
>
> 1) Do nothing, and rely on social controls.
I'm not worried about social controls so much as overall exposure.
> 2) Forbid the auto-updating of websites; say that it has to be done
> manually.
Not practical.
> 3) Put those sites at Level 3 instead of 2 (but this would require
> another set of entry criteria for Level 3, and the overlap in
> personnel is not great)
Doesn't really make a lot of sense.
> 4) Create two Level 3s - Level 3 (websites) and Level 3 (code). This
> would require technical changes, hence my desire to work out what we
> want to do quickly.
This seems like the only viable option of the four, but I'm really
really not sure this is right. The exposure for any one site is
limited to a small set of people. Creating a larger group just
increases the potential exposure, so I'd want to know how much overlap
exists among the groups that have access across the "core" repos in
SVN, and how much added exposure we'll get vs. preserving per-repo
permissions for a handful of production repos.
Can we exclude the "core" SVN repos from the changeover, and retain
per-repo permissions until this is settled?
-- Mike
Robert Kaiser
> We recently finalized the Commit Access Policy:
> https://wiki.mozilla.org/Commit_Access_Policy
As a final policy, it should live on www.mozilla.org and not on the
wiki, actually. Any plans for that?
Robert Kaiser
davidwboswell
about some of the reasons behind this proposed change and the
technical issues with the repositories. With that having been said,
the following may be completely stupid questions :)
Why wouldn't we be able to continue restricting access to a given
website to a certain group of people? You mention that having a level
3 website category would require technical changes, but we're
restricting access to a subset of SVN users right now.
If we did create a new level that was specific to websites does that
mean that anyone in that level would have access to any of the
websites?
In terms of amount of overlap, the core directories and the website
directories are like apples and oranges and I'd be surprised if there
were more than a small handful of people committing to both. I think
it's the same across websites -- there is some overlap but not a whole
bunch.
David
Pascal Chevrel
>
> Can we exclude the "core" SVN repos from the changeover, and retain
> per-repo permissions until this is settled?
>
+1
We currently have a solution that is safe and flexible for our sites (no
commit rights to the production tag) and that does not cause too much
red tape for localizers who are probably the biggest group of committers
to svn (one l10n driver as voucher + signed committer's agreement).
I see how applying this new policy could break all of our websites or
cause big troubles in case we publish stuff too early, what I don't see
is what benefits it will bring to the current situation, therefore I am
in favor of not breaking something that works well for us today.
Pascal
Gervase Markham
> Are you also thinking of keeping the policy on the wiki or were you
> just editing it there? From earlier discussions about policies
> several people felt that having policies on a wiki conveyed an image
> of the document being a draft and incomplete even if this wasn't the
> case.
Yes, I think once it's finished we can move it to www.mozilla.org.
Gerv
Gervase Markham
> Why wouldn't we be able to continue restricting access to a given
> website to a certain group of people? You mention that having a level
> 3 website category would require technical changes, but we're
> restricting access to a subset of SVN users right now.
It's not a question of technical ability. We have the ability, should we
wish to, to retain separate access control lists for every individual
repository we have. However, the complexity of that is seen as
outweighing the gain.
> If we did create a new level that was specific to websites does that
> mean that anyone in that level would have access to any of the
> websites?
That is my suggestion (for websites we define as "production websites").
Social controls would prevent people doing the wrong thing. Trust should
be transitive. If I'm trusted enough by the project to update the front
page of www.mozilla.org, then I don't see an issue with me having the
technical ability to update addons.mozilla.org, even if I never do it.
(I'm anticipating, though, that it would be a fairly small set of people
who have this ability.)
Gerv
Gervase Markham
> We currently have a solution that is safe and flexible for our sites (no
> commit rights to the production tag)
Ah - so the current system is that lots of people can commit to the
www.mozilla.com repo (for example) but only a few people can move the
"production" tag?
I didn't realise that was possible. That sounds like a great way of
splitting the difference. Leave things as they are, but just have a
small group who have the ability to move that tag around.
Gerv
Gervase Markham
> This seems like the only viable option of the four, but I'm really
> really not sure this is right. The exposure for any one site is limited
> to a small set of people. Creating a larger group just increases the
> potential exposure, so I'd want to know how much overlap exists among
> the groups that have access across the "core" repos in SVN, and how much
> added exposure we'll get vs. preserving per-repo permissions for a
> handful of production repos.
It would be helpful to have a list of the repos we consider to be
"production" in this sense. I've asked Reed if he doesn't mind making one.
> Can we exclude the "core" SVN repos from the changeover, and retain
> per-repo permissions until this is settled?
We need that list first, so we know which ones those are :-)
Gerv
Mitchell Baker
I understand the desire to have these live on mozilla.org. However, I
could not find mozilla policies last time i went looking -- I had to
email Gerv and ask where they are. Searching for "policy" did not find
them, even when searching only in the mozilla universe. (I know that
I could have found them by navigating around the site and coming to
About, then policies, but that's not how many of us actually use the web
today.)
So right now I think we have a setting that feels "pure" from a logic,
organizational point but is not helping us actually manage the project
well. I already know we have policies, I was explicitly looking for
them, but couldn't find them. Searching for "policy" in the mozilla
world leads to policies at our developer documentation site. I think
this will be the case because so many more people use the documentation
site, so relative rankings are likely to continue to point here.
I know we had a big discussion re where these should live. I don't
actually care personally -- I would put them wherever most people would
find them, use them, and participate in their development. I understand
others feel different, and deeply. I'm fine with leaving them at
mozilla.org (I do grok the logic) but want to make them much more
findable. If that means including info about them at the developer docs
site I would do that.
Does anyone have other ideas?
Mitchell
Mike Connor
On 2010-02-26, at 11:34 AM, Mitchell Baker wrote:
> I know we had a big discussion re where these should live. I don't
> actually care personally -- I would put them wherever most people
> would find them, use them, and participate in their development. I
> understand others feel different, and deeply. I'm fine with leaving
> them at mozilla.org (I do grok the logic) but want to make them
> much more findable. If that means including info about them at the
> developer docs site I would do that.
>
> Does anyone have other ideas?
Hmm, there's definitely a lack of strong organization of our policies,
let alone even a small dose of SEO. They're not in the same place, or
part of a shared taxonomy, though there's a place they are all linked
[1], which is linked from the page footer. "mozilla policies" gets
you to the right place, but "mozilla policy" does not. I think some
straightforward content organization and tweaking to make the main doc
(and the key policy docs) much easier to find would help a great deal
here. Something like [2] would work better here, I think.
David, any thoughts on an organization like this?
-- Mike
[1] http://www.mozilla.org/about/policies/
[2]
mozilla.org
/policy
/module-ownership
/development
/code-review
/commit-access
/performance-regressions
/incubator-repos
/code-licensing
/privacy
/website
/firefox
/security
/bugs
/ca-certificates
/trademarks
/policy
/l10n-policy
/1l0n-web-policy
/partners
/website
/markup
/content
Dan Mosedale
>
> On 2010-02-26, at 11:34 AM, Mitchell Baker wrote:
>
>> actually care personally -- I would put them wherever most people
>> would find them, use them, and participate in their development. I
>> understand others feel different, and deeply. I'm fine with leaving
>> them at mozilla.org (I do grok the logic) but want to make them
>> much more findable. If that means including info about them at the
>> developer docs site I would do that.
>>
>> Does anyone have other ideas?
>
> let alone even a small dose of SEO.
marketing with SEO experience who could offer advice here?
Dan
davidwboswell
> world leads to policies at our developer documentation site. I think
> this will be the case because so many more people use the documentation
> site, so relative rankings are likely to continue to point here.
FWIW, earlier this week there was an issue with someone coming across
a very old piece of documentation on mozilla.org even though there was
newer documentation on MDC, because the first entry in Google for
'http logging' was pointing to mozilla.org.
I don't know enough about SEO to know why in one instance the first
entry of a search went to MDC and the first of another went to
mozilla.org, but there are certainly things we can do to point people
in the right direction -- including people who are searching for
things and also people who are going to a Mozilla site and trying to
navigate to a particular place.
Although this might not solve all of the problem, I think physically
aggregating policies in one place (such as in mozilla.org/about/
policies following Mike's suggestion) would help make things more
discoverable.
Beyond where things live though, just having a complete set of links
on the Policies page would help. The Commit Access Policy we've been
talking about hasn't been linked to from this page yet which is
clearly not helping :) Gerv, feel free to add the link or let me know
how you'd like it to be placed on the page.
David
davidwboswell
Seems reasonable to me. I opened a bug about making policies easier
to find and added this and a few other ideas.
https://bugzilla.mozilla.org/show_bug.cgi?id=548902
Please feel free to comment there with any thoughts about making
things easier to find.
David
morgamic
understand the motivation for issuing a blanket policy for SVN that
grants access to any path to anybody with an account. My concerns
with this are:
1. Security. Yes, auto-update is a concern but even if not we've got
a lot of projects in here and social controls are no substitute for
ACLs. In the event where people get their accounts compromised, it's
a lot easier to track down any subsequent changes if they have limited
access. Same reason why when you give a web application a database
user, you don't give that user grant and other permissions to the
database if they don't need it. It's standard practice to whitelist
access.
2. Accountability. The benefit of the level 3 system is that
ultimately someone is responsible for changes in any project in SVN.
If you give system-wide access to any account, this becomes
considerably more difficult. I wouldn't reasonably expect a module
owner to be responsible for all changes to a particular project in
this type of system. This presents a lot of questions about the
viability of handling access this way.
3. Change for change's sake. I don't see the inherit benefits of
abandoning a system that for the most part has worked for SVN.
Despite not being code that gets shipped in Firefox, it still contains
things that integrate directly into Firefox via the service layer,
code that drives our main corporate and foundation websites and most
of the code behind all Mozilla web properties. I think we're
underestimating the impact and importance of this code repo -- and if
we are going to change the access policy surrounding it we better have
a good reason. Right now I don't see that reason. Furthermore, we
can't just replace it with "social controls" without having those well-
defined. And even if they are, I'd choose ACLs over social controls
because they are written somewhere, have a record (in bugzilla) and
are explicit on a per-project basis.
Mike
Mitchell Baker
>
> Although this might not solve all of the problem, I think physically
> aggregating policies in one place (such as in mozilla.org/about/
> policies following Mike's suggestion) would help make things more
> discoverable.
>
I am not yet a fan of aggregating all policies on
mozilla.org/about/policies.
I am a fan of putting policies where they are most likely to be found,
and where we can make them most easily findable. That's not
about/policies right now.
> David
>
>
>
Justin Wood (Callek)
IMO, if we have one central place that identifies and gets us to EVERY
(or at least most) policies it will greatly benefit us as a whole.
For example I know the commit policy is linked from there, and I know
other policies are too. I'm in #firefox on IRC and someone asks about
the Weave Extension and it leads to questions about privacy, I can
quickly get the weave privacy policy link for the person without needing
to question myself on "where the right place is" not really knowing MUCH
{of anything} about the project.
Similar examples will apply for other policies based on personal sets of
interests and prior knowledge.
I'm not saying that we should force every policy to ONLY have links from
mozilla.org but I'd be a BIG fan of having them HOSTED there, and LINKED
from "where they would likely be found." {More links would also help
infer the Search Engines}
--
~Justin Wood (Callek)
Mitchell Baker
>
>
> I'm not saying that we should force every policy to ONLY have links from
> mozilla.org but I'd be a BIG fan of having them HOSTED there, and LINKED
> from "where they would likely be found."
This would work. The reverse would also work, having the links at
mozilla.org. I know some people object to this based on the idea that
mozilla.org *should* be the canonical home. I'm on the practical side,
care mostly that stuff can be found. If we can do that with mozilla.org
as the home, great.
mitchell
Max Kanat-Alexander
> Thoughts?
Why not change the policy so that within Level 2, one only gets access
to the modules one has been vouched for? That would allow less-strict
voucher requirements and handle any possible issue similar to this one
in the future.
The original problem that spawned the new policy was a problem of
understanding requirements, not a technical problem of implementing
them, right? So this would still be a very simple and understandable
policy, while also avoiding any problems with granting people access
that was too broad.
-Max
Pascal Chevrel
Yes, that's exactly how it works now, I think we have like 5 people that
can merge files to the production tag from trunk but about 100 that can
commit to trunk.
Pascal
Gervase Markham
> Why not change the policy so that within Level 2, one only gets access
> to the modules one has been vouched for? That would allow less-strict
> voucher requirements and handle any possible issue similar to this one
> in the future.
There is no technical reason we couldn't do that, but it would be a
greater administrative burden, because people whose work spanned or came
to span multiple areas of the project would regularly need to seek new
tweaks to their permissions.
My argument is that, to a certain extent (and that extent is, in a
sense, what we are discussing here) trust is transitive - if we as a
project trust someone to check in to some of our repos, we trust them
with the ability to check in to other ones, even if they never use it.
> The original problem that spawned the new policy was a problem of
> understanding requirements, not a technical problem of implementing
> them, right? So this would still be a very simple and understandable
> policy, while also avoiding any problems with granting people access
> that was too broad.
The meta aim of the policy is to make everyone's lives easier - those
who are applying for access, those who are using it, those who are
vouching, and those who are implementing the rules.
Gerv
Gervase Markham
> Hey, just some thoughts on the proposed access changes. I don't
> understand the motivation for issuing a blanket policy for SVN that
> grants access to any path to anybody with an account.
Indeed; the original policy proposed this due to a lack of complete
understanding about the nature of the SVN repository. No-one is
suggesting it now.
A new proposal is to keep all the website trees at policy level 2 (to
allow maximum easy collaboration, e.g. from localizers), but have a
(much) smaller single set of people who are trusted to push things to
production (i.e. can move or merge code to the "production" tag) on a
defined set of important trees.
Would that alleviate your concerns?
> ACLs. In the event where people get their accounts compromised, it's
> a lot easier to track down any subsequent changes if they have limited
> access.
I'm not sure that's true. Each change is labelled with the user who made
it, and so can be tracked, whether accounts have broad or narrow
permissions.
You might argue that compromised accounts have reduced potential for
damage the more ACLs we have. That is true in general, but we need to
find the medium between "every single tree has its own ACL" (which would
be an administrative nightmare IMO, and cause unnecessary friction as
people try and collaborate) and having one big repo everyone gets access
to.
Policy 1.0 was one attempt at striking that balance; this discussion is
happening because it's clear it got it wrong in this instance.
Gerv
davidwboswell
> allow maximum easy collaboration, e.g. from localizers), but have a
> (much) smaller single set of people who are trusted to push things to
> production (i.e. can move or merge code to the "production" tag) on a
> defined set of important trees.
>
> Would that alleviate your concerns?
I'm not sure how widely the mozilla.com push to production model is
used, but mozilla.org does not have this same flow. Commits to trunk
are automatically made live.
David
Max Kanat-Alexander
> My argument is that, to a certain extent (and that extent is, in a
> sense, what we are discussing here) trust is transitive - if we as a
> project trust someone to check in to some of our repos, we trust them
> with the ability to check in to other ones, even if they never use it.
Sure. And the current policy page on mozilla.org says that there's
never been a malicious incident, so the policy revisions clearly aren't
worried about it from a security perspective. I think it would be more
an issue of preventing mistakes--sometimes new committers aren't
familiar with a VCS, or there's a chance they might accidentally commit
to the wrong repo, etc.
I'm personally fine with granting people access to everything at Level
2, it's just that the following two statements seem logically
contradictory to me:
* There's not a trust problem--security hasn't ever historically been
an issue, and if we trust people enough to commit to one branch, they
can commit to any branch.
* Only module owners may vouch, because of a trust problem.
Also (and more importantly than the above, which doesn't really matter
too much in the end, because as you pointed out in another thread, there
aren't zillions of new committers every day) who's to say that the same
issue that we're discussing in this thread won't happen with other
things than production websites in the future? (Maybe it's even an issue
right now; I don't know if all of Mozilla's module owners subscribe to
this newsgroup.) What if there need to be all sorts of special
exceptions for different things? Then we'd creep right back up to the
current system's complexity.
-Max
Pascal Chevrel
mozilla.org is the exception and this is a bug IMO, almost all mozilla
sites have a trunk/production model (and often a trunk/stage/production).
Pascal
Mike Connor
On 2010-03-01, at 5:13 PM, Pascal Chevrel wrote:
It's not a bug, IMO. Just because other sites are more locked down
doesn't mean we need to change how mozilla.org has worked since (at
least) 2003. Having to tag something every time someone edits a
document is onerous at best.
-- Mike
Robert Kaiser
> I'm personally fine with granting people access to everything at Level
> 2, it's just that the following two statements seem logically
> contradictory to me:
>
> * There's not a trust problem--security hasn't ever historically been
> an issue, and if we trust people enough to commit to one branch, they
> can commit to any branch.
> * Only module owners may vouch, because of a trust problem.
I don't see a contradiction there. Basically, what we're stating in
those two is that we set the entry level high enough that we can trust
someone with commit access enough to have access to more than what he
needs every day.
Robert Kaiser
davidwboswell
> sites have a trunk/production model (and often a trunk/stage/production).
This might be getting a bit off topic, but mozilla.org has different
requirements and a wider and less coordinated group of editors than
mozilla.com and just copying that workflow won't necessarily work.
I'm not opposed to changing the mozilla.org workflow based on a new
commit policy if needed, but I'd like to change to something suited to
the site's needs.
David
Max Kanat-Alexander
> I don't see a contradiction there. Basically, what we're stating in
> those two is that we set the entry level high enough that we can trust
> someone with commit access enough to have access to more than what he
> needs every day.
That's fair enough.
My other point below, though, about the future and flexibility of the
system, though, still stands.
-Max
Pascal Chevrel
> Due to the way SVN works, this allows projects/mozilla.com/trunk to be
> level 2, for ease of collaboration and localization, but we can still
> keep the production tag restricted to a specific set of people.
>
> We would obviously work out what the correct initial list of exceptions
> was before fully deploying the policy.
>
> Does that work for people?
Good for me :)
Pascal
davidwboswell
> We would obviously work out what the correct initial list of exceptions
> was before fully deploying the policy.
This seems reasonable to me.
BTW, your post about this update to the commit policy doesn't seem to
be showing up in Google Groups, although Pascal's reply did (maybe I'm
just missing it?). Might be worth reposting to make sure everyone
sees your suggestion.
David
Gervase Markham
On 25/02/10 14:03, Gervase Markham wrote:
> We recently finalized the Commit Access Policy:
> https://wiki.mozilla.org/Commit_Access_Policy
>
> However, there is a problem which might require a further change. We
> need to resolve it quickly because IT are in the middle of implementing
> the technical changes for the current policy.
Here is a proposal.
The aim of the new Commit Access policy is to achieve simplicity, which
benefits everyone. So how about we make simplicity the default, but
allow people to opt for something else?
The policy as currently written has three levels. The normal procedure
would be for any particular tree or path to be open to everyone with
access at a particular level. So user trees would default to level 1,
core code trees would default to level 3, and other trees would default
to level 2. (This list is not exhaustive; you get the idea.) People
creating new trees would either have access be the default for the sort
of tree they were creating, or they could explicitly choose another
level if they wanted to.
However, we would also keep a list of exceptions, each of which had a
separate ACL. The exceptions list would include the contact person who
you had to contact to get access to that tree or path. So that list
might be in part:
SVN projects/mozilla.com/tags/production jsl...@mozilla.com
Bzr bugzilla mka...@bugzilla.org
Hg penelope som...@qualcomm.com
...
IOW, people could just pick the easy, open, collaborative option but if
there was a need for something more restrictive, they could have that -
as long as it was clear who you had to contact to get access.
Due to the way SVN works, this allows projects/mozilla.com/trunk to be
level 2, for ease of collaboration and localization, but we can still
keep the production tag restricted to a specific set of people.
We would obviously work out what the correct initial list of exceptions
was before fully deploying the policy.
Does that work for people?
Gerv
Mike Connor
I think as a blanket rule, any project actively using a production tag or tags in SVN should be on the exception list by default, but beyond that I think this is just fine.
-- Mike
Gervase Markham
> I think as a blanket rule, any project actively using a production
> tag or tags in SVN should be on the exception list by default, but
> beyond that I think this is just fine.
They can certainly be added - but the trouble with adding them "by
default" is that, if there's no specific application, you don't know who
is the person nominated as responsible for granting access. And I think
having a nominated person is important for transparency and easy admin.
I'll try and draft the exceptions list this week, for comment.
Gerv