Revoking Commit Access
Mitchell Baker
Draft is below. I hope to keep this simple. We don't want to encourage
a lot of complaints because people don't like each other, or someone
has a bad day or whatever; this should be for serious problems.
Similarly my inclination is not to create an elaborate process unless /
until we find we need one.
When finalized, a paragraph on revoking commit access will appear in the
new Commit Access Policy doc. If I don't hear otherwise, the paragraph
will be basically the one below.
Comments welcome.
mitchell
Revocation of Commit Access: If someone consistently causes
difficulties with these source repositories due to poor behavior or
other serious problems then commit access may be revoked. We have no
precise process for this as it has been a rare or nonexistent problem to
date. The process for this is for one or more committers with concerns
to notify the owner of the Commit Access Policy sub-module if you have
clear examples of someone whom you believe has reached this level of
problem. Do not do so carelessly, or based on passing irritation or
without a sense that you are not alone in your concerns. The Commit
Access Policy owner will investigate or cause an investigation to occur,
privately at first and perhaps completely privately.
Mike Shaver
> One thing this doesn't cover is natural expiration of commit access. I
> think, for security reasons as well as just proper community care and
> maintenance, if someone hasn't used their commit access for, say, 2 years,
> they probably don't need it anymore and it should be turned off. Or perhaps
> made dormant, and easily restored with a quick proof of identity.
I would say dormant, and a comment reopening their original access bug
sufficing to restore, on a 6-month timer. Tracking that timer
properly (people use commit access to push to try, f.e.) will be some
work, but I think your intent is very good. (Restoring after some
period of time may not always want to be automatic, though; someone
who was last active before we had try and test suites, f.e., would
probably need a refresher on that before they pushed. May not need
policy coverage, but probably warrants a "please refresh yourself on
this doc!" when access is restored.)
I think that's different from revoking access, though, and is more
like a password rotation policy. I'd group it into a more general
account-hygiene thing, along with maybe stripping the sec-bugs bit if
someone hasn't accessed a security bug in 2 months, etc., separate
from this active revoke for cause.
Mike
Mitchell Baker
Dorman Accounts
If an account has not been used for a year it may be shifted
to a "dormant" account. This is not a revocation-for-cause as described
above. Returning a dormant account to active status is a matter of the
owner requesting this (by reopening his or her original commit access
bug) and a review to determine if any significant new "best practices"
have been adopted that the committer should be aware of prior to
restoration. For example, someone who was last active before the
widespread use of try servers and test suites should indicate in the
bug that he or she has familiarized himself or herself with these new
requirements before the account is activated.
mitchell
Robert Kaiser
> Dorman Accounts
+t please :)
> If an account has not been used for a year it may be shifted
> to a "dormant" account.
This sounds very good to me. We have gone quite long so far without such
a policy, but it has always made me somewhat nervous that commit access
never expires at all.
Robert Kaiser
Mitchell Baker
On 6/2/09 1:15 PM, Mitchell Baker wrote:
Here's what i put in the revised document. Not a lot of details. Last time we started down the path for 6 month review of accounts there was a lot of disagreement -- Zak started this discussion, don't quite recall when. So i went to one year.
Dorman Accounts
If an account has not been used for a year it may be shifted
to a "dormant" account. This is not a revocation-for-cause as described
above. Returning a dormant account to active status is a matter of the
owner requesting this (by reopening his or her original commit access
bug) and a review to determine if any significant new "best practices"
have been adopted that the committer should be aware of prior to
restoration. For example, someone who was last active before the
widespread use of try servers and test suites should indicate in the
bug that he or she has familiarized himself or herself with these new
requirements before the account is activated.
This seems good to me; I assume we'll want to have someone sign up to be on the hook for doing that review work with reasonable turnaround before actually adopting this as policy? Is this the module owner for the Commit Access Policy, perhaps?For a number of policies I think we'll want to identify two people -- the owner, and the person responsible for implementing the policy. In some cases these may be the same, but often they will be different. For example, Frank should clearly remain the owner of the CA Policy, which sets out the criteria a CA must meet to be included in our products. But there's no reason Frank should be the implementor -- the person reviewing CA applications. Frank owns the policy on handling security bugs, but again he's not the main implementor; those are in the product teams.
Dan
Similarly, I'm likely to be the first owner for the Commit Access Policy, but not the best at reviewing who's done what. Or at responsing when someone points out a committer who's been dormant for a long time. I'll probably look for someone other than me to do this.
ml
Nelson Bolyard
If so, why?
Don't Hg accounts also fall into disuse?
What about the user whose CVS account falls into disuse but actively uses
his Hg account, or vice versa?
Is the idea to manage accounts in CVS and Hg separately?
Or is this policy intended to apply to all of a user's commit rights in all
Mozilla repositories?
Gervase Markham
> Is this policy really limited to CVS accounts, as the thread subject suggests?
I don't think so; I think "CVS" is being used in the sense of "VCS" ;-)
> What about the user whose CVS account falls into disuse but actively uses
> his Hg account, or vice versa?
I think it would make sense, if technically feasible, to disable all
accounts in parallel and use activity on any of them to reset the clock.
Gerv
timeless
Oh, that's interesting. I assumed we really meant CVS and not VCS.
There's actually an argument for it too..., but given that we're using
ssh keys globally, the argument is extremely weak.
Gervase Markham
> Oh, that's interesting. I assumed we really meant CVS and not VCS.
Well, I could be wrong :-) But it's what I'd assumed.
Gerv
Robert Accettura
That's my understanding as well... I think it's also /per/ vcs as
opposed to any. So your cvs account could be inactive while your hg
account is in use... Or vice versa.
Mitchell Baker
Sorry, use of "CVS" is an old habit that dies hard. I too think we mean
any repository. The motivation is as Mike described, reducing risk
of accounts being compromised, and particularly compromised without
being noticed. That concern appies to all repositories.
And i think "per account" is probably right -- if someone has been
working in Hg repos exclusively for a year, then the risk for the old
CVS account is lower than if the person has left the project, but still
enough to warrent attention.
If it turns out this is a big technical problem we could start with a
system that is per *person* rather than per repository.
Mitchlll
Mitchell Baker
Sorry, use of "CVS" is an old habit that dies hard. I too think we mean
Mike Shaver
weekend (what a life) and realized that we're trying to solve with
policy what might be effectively and less-intrusively soluble with
technology.
My premise is that the problem with dormant accounts is that their use
or misuse might not be noticed by the legitimate user. So what if a
Qualifying Activity, when performed more than 3 months since the last
Qualifying Activity, the account holder and some group like
dev-tree-management or sheriffs are mailed a "welcome back! remember
to check this list for things that might have changed, and thanks for
your contribution!" email. That would let us audit for the bad cases
pretty effectively, IMO, without adding a policy burden _or_ an IT
workflow burden for re-enabling. At least for ssh-based services,
where the risk of password re-use or brute-forcing is smaller, I think
this would be effective.
We could also mail people who have been inactive for N months with a
"we understand people get busy, but if you're not using your account
we'd appreciate it if you'd wander over here and mark yourself as
dormant -- it helps us keep track of active contributors, and it's
easy to change back when you have time to get involved again".
Mike
Mitchell Baker
I'd like to update the Commit Access Policy on the issues we've resolved
while we work on the Dormant Account piece. That way the rules for
getting Commit Access will change this week -- as early as tomorrow -
and we can alleviate that set of issues. I think it will take longer to
figure out what we're going to do with Dormant Accounts. To do this I
would include a paragraph saying we're working on a plan for dormant
accounts. That language is:
Proposed Language of intent regarding dormant accounts
Dormant Accounts:
As of June 2009 we're working on a plan for addressing accounts that
have seen no activity for some specified period of time. We may disable
such accounts. Assuming we do this, the process for reactivating them
will be a much more lightweight process than that for obtaining commit
access the first time.
Any objection?
mitchell
Mike Shaver
> Dormant Accounts:
>
> As of June 2009 we're working on a plan for addressing accounts that have
> seen no activity for some specified period of time. We may disable such
> accounts. Assuming we do this, the process for reactivating them will be a
> much more lightweight process than that for obtaining commit access the
> first time.
>
> Any objection?
WFM.
Mike
Robert Accettura
> Not to muddy the waters, but I've been thinking about this over the
> weekend (what a life) and realized that we're trying to solve with
> policy what might be effectively and less-intrusively soluble with
> technology.
>
> My premise is that the problem with dormant accounts is that their use
> or misuse might not be noticed by the legitimate user. So what if a
> Qualifying Activity, when performed more than 3 months since the last
> Qualifying Activity, the account holder and some group like
> dev-tree-management or sheriffs are mailed a "welcome back! remember
> to check this list for things that might have changed, and thanks for
> your contribution!" email. That would let us audit for the bad cases
> pretty effectively, IMO, without adding a policy burden _or_ an IT
> workflow burden for re-enabling. At least for ssh-based services,
> where the risk of password re-use or brute-forcing is smaller, I think
> this would be effective.
>
> We could also mail people who have been inactive for N months with a
> "we understand people get busy, but if you're not using your account
> we'd appreciate it if you'd wander over here and mark yourself as
> dormant -- it helps us keep track of active contributors, and it's
> easy to change back when you have time to get involved again".
>
I think (correct me if I'm wrong) it's been successfully argued that
illegitimate use of a vcs account would be noticed and rectified during the
voucher discussions over the past few weeks. Hence the argument for less
review over getting vcs privileges and more emphasis on code review process
and trust in reviewers/super reviewers.
I'm not terribly fond of the email method since the first of the month is
"mailing list reminder day"... and I never bother opening one of them. I
*think* this will result in the same reflex forming very quickly.
What about taking all vcs commits (svn, hg, cvs) and logging them into a
unified location for the purpose of getting more eyes on them (rather than
bonsai, hg's changelog, and svn's log). Then perhaps based on frequency of
commits, projects effected, ip used for the commit (never before seen IP is
higher risk) colorize or mark them based on risk. Modernizing with RSS
would also help. I think getting more eyes on them, and helping put focus
on "higher risk" commits would have an immediate effect on mitigating risk.
Is there any vcs in use that isn't can be accessed from outside the firewall
without a ssh key? There are many solutions out there to blacklist brute
force attempts on OpenSSH... even if you gave 20 attempts before
blacklisting (most I've seen employ 3-6)... what are the statistical odds of
someone getting through?
That said, I do agree technology can solve at least part, if not the entire
thing.
timeless
> Not to muddy the waters, but I've been thinking about this over the
> weekend (what a life)
:)
> and realized that we're trying to solve with
> policy what might be effectively and less-intrusively soluble with
> technology.
> My premise is that the problem with dormant accounts is that their use
> or misuse might not be noticed by the legitimate user. So what if a
> Qualifying Activity, when performed more than 3 months since the last
> Qualifying Activity, the account holder and some group like
> dev-tree-management or sheriffs are mailed a "welcome back! remember
> to check this list for things that might have changed, and thanks for
> your contribution!" email.
this sounds great actually.
> That would let us audit for the bad cases
> pretty effectively, IMO, without adding a policy burden _or_ an IT
> workflow burden for re-enabling. At least for ssh-based services,
> where the risk of password re-use or brute-forcing is smaller, I think
> this would be effective.
>
> We could also mail people who have been inactive for N months with a
> "we understand people get busy, but if you're not using your account
> we'd appreciate it if you'd wander over here and mark yourself as
> dormant -- it helps us keep track of active contributors, and it's
> easy to change back when you have time to get involved again".
this also sounds good. we should probably collect bounces too for both.
Dan Mosedale
> On Mon, Jun 8, 2009 at 10:24 AM, Mike Shaver<mike....@gmail.com>
> wrote:
>> "we understand people get busy, but if you're not using your account
>> we'd appreciate it if you'd wander over here and mark yourself as
>> dormant -- it helps us keep track of active contributors, and it's
>> easy to change back when you have time to get involved again".
> illegitimate use of a vcs account would be noticed and rectified
> during the
> voucher discussions over the past few weeks. Hence the argument for less
> review over getting vcs privileges and more emphasis on code review
> process
> and trust in reviewers/super reviewers.
>
> I'm not terribly fond of the email method since the first of the month is
> "mailing list reminder day"... and I never bother opening one of them. I
> *think* this will result in the same reflex forming very quickly.
person, if this were to a be a problem at all (of which I'm not
convinced), it seems like it would be one of for a much smaller
percentage of users.
> What about taking all vcs commits (svn, hg, cvs) and logging them into a
> unified location for the purpose of getting more eyes on them (rather
> than
> bonsai, hg's changelog, and svn's log). Then perhaps based on
> frequency of
> commits, projects effected, ip used for the commit (never before seen
> IP is
> higher risk) colorize or mark them based on risk. Modernizing with RSS
> would also help. I think getting more eyes on them, and helping put
> focus
> on "higher risk" commits would have an immediate effect on mitigating
> risk.
interesting metrics from such a database, in addition to just flagging
checkins to risky code. That said, this sounds like a non-trivial
amount of work that someone would need to sign up for.
Robert Kaiser
> Proposed Language of intent regarding dormant accounts
>
>
> Dormant Accounts:
>
> As of June 2009 we're working on a plan for addressing accounts that
> have seen no activity for some specified period of time. We may disable
> such accounts. Assuming we do this, the process for reactivating them
> will be a much more lightweight process than that for obtaining commit
> access the first time.
>
> Any objection?
Sounds good to me, let's not push out the updates for the policy as a
whole and instead put that paragraph there until we agree on what to do
exactly.
Robert Kaiser
Robert Kaiser
> We could also mail people who have been inactive for N months with a
> "we understand people get busy, but if you're not using your account
> we'd appreciate it if you'd wander over here and mark yourself as
> dormant -- it helps us keep track of active contributors, and it's
> easy to change back when you have time to get involved again".
That makes people who abandoned their account entirely (including email)
never become dormant (same for people who are for some reason unable to
do anything on the Internet anymore - imprisonment, death, whatever),
which is probably not what we want in that case.
Robert Kaiser
Mike Shaver
> Mike Shaver wrote:
>>
>> We could
>> also
>> mail people who have been inactive for N months with a
>
> That makes people who abandoned their account entirely (including email)
> never become dormant (same for people who are for some reason unable to do
> anything on the Internet anymore - imprisonment, death, whatever), which is
> probably not what we want in that case.
"Also", and N for reminder-mail could be smaller than M for
auto-dormanting. If a reminder bounces, of course, then you can make
it dormant.
Mike