Fwd: Re: Making CVS accounts become "dormant" after 1 year of no use
Dan Mosedale
> 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? I assume that person is likely to be
either the module owner for the Commit Access Policy or someone that
they delegate to?
Dan
Gervase Markham
> 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? I assume that person is likely to be
> either the module owner for the Commit Access Policy or someone that
> they delegate to?
Sounds reasonable. Although I myself expect this sort of reactivation to
be reasonably rare. I can't think of many people who have gone away for
more than a year and then come back.
Gerv
Justin Dolske
> Sounds reasonable. Although I myself expect this sort of reactivation to
> be reasonably rare. I can't think of many people who have gone away for
> more than a year and then come back.
IIRC, we didn't give inactive CVS account Hg access when we opened up
mozilla-central last year. I don't remember an outcry over that, which
would seem like evidence that this policy should be fine.
Also, did we ever shutdown accounts that hadn't submitted a Committer's
Agreement 2.0?
Justin
timeless
> Sounds reasonable. Although I myself expect this sort of reactivation to be
> reasonably rare. I can't think of many people who have gone away for more
> than a year and then come back.
I can. And personally I don't often make cvs commits, but it wouldn't
shock me if i wanted to make a cvs commit a year from now even though
I don't regularly commit to cvs.
fantasai
I would be one of those people, btw. :)
~fantasai
Mike Shaver
> On Wed, Jun 3, 2009 at 10:13 PM, Gervase Markham <ge...@mozilla.org> wrote:
>> reasonably rare. I can't think of many people who have gone away for more
>> than a year and then come back.
>
> shock me if i wanted to make a cvs commit a year from now even though
> I don't regularly commit to cvs.
You can think of _many_, or you can think of _some_? Making policy on
the basis of the extent of your imagination is probably not a sound
strategy here.
I was a year away from committing at some point, I'm sure, but I
wouldn't have minded needing to ask to have it re-enabled. And this
was before checkin-needed or the try server! It shouldn't be onerous
to do so, especially if there haven't been any major changes in how we
operate in the intervening time.
Mike
Mitchell Baker
I tried to be lightweight in process. the language now reads
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). The person making such a request should ask a current committer 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 talk to an active committer specifically to familiarized
himself or herself with these new requirements. The person requesting
reinvigorating a dormant account should note in the bug when this
discussion has happened before the account is reactivated.
Mike Shaver
> If an account has not been used for a year it may be shifted to a "dormant"
> account.
I think a year is too long here; I don't think we should be biasing
towards the convenience of someone who commits every 8 months, and
away from reducing our attack surface.
Even 6 months is longer than I'd like, and I know that I'd bump into
that limit relatively frequently! (Zak's previous thread was about
just deleting the account, IIRC, not putting it into a
more-easily-reverted dormant state, which is likely why there was more
pushback on the timeframe.)
> The person making such
> a request should ask a current committer 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 talk to an active committer
> specifically to familiarized himself or herself with these new requirements.
I think that staying on top of best practices or requirements is the
responsibility of the account holder, and he or she shouldn't be
relying on another active committer to know the delta between the
person's last commit and the current date. The language here makes it
sounds like it's the active committer's responsibility to "sign off"
on the person's currency, and that doesn't seem like it matches what
we do with everyone else. You can certainly go away just for 2 months
and come back to find a totally new super-review policy, f.e., so this
could just be a reference to the committer-guide text on "staying
current on practices and requirements is your responsibility".
Mike
Dan Mosedale
> I think a year is too long here; I don't think we should be biasing
> towards the convenience of someone who commits every 8 months, and
> away from reducing our attack surface.
> I think that staying on top of best practices or requirements is the
> responsibility of the account holder, and he or she shouldn't be
> relying on another active committer to know the delta between the
> person's last commit and the current date. The language here makes it
> sounds like it's the active committer's responsibility to "sign off"
> on the person's currency, and that doesn't seem like it matches what
> we do with everyone else. You can certainly go away just for 2 months
> and come back to find a totally new super-review policy, f.e., so this
> could just be a reference to the committer-guide text on "staying
> current on practices and requirements is your responsibility".
problem of finding the approximate set of policy/cultural changes that
happened during someone's absence. It's not clear to me how a person
would go about finding out that set of things in the current world,
regardless of whether the person in question was the committer or
someone who had stayed involved.
Do we need some central repository for this information? One thing that
comes to mind is that if we had another monthly about: newsletter that
focussed specifically on stuff relevant to checkins and coding
(about:hacking?), people could at least just go skim the back issues to
see the important changes...
Dan
Dave Townsend
> Do we need some central repository for this information? One thing that
> comes to mind is that if we had another monthly about: newsletter that
> focussed specifically on stuff relevant to checkins and coding
> (about:hacking?), people could at least just go skim the back issues to
> see the important changes...
Do we have a comprehensive MDC article on committing rules and
responsibilities? I couldn't find one but seems like we should have.
Wiki pages can show what changed since date X right?
Newsletter seems like a bit too much, we don't change this stuff often
do we? Though I seem to recall I am signed up to some committer's
mailing list that I have never received anything from. Not sure if that
was an automatic thing.
Gervase Markham
> Also, did we ever shutdown accounts that hadn't submitted a Committer's
> Agreement 2.0?
This will happen... eventually :-) But first the people who haven't
signed one need to be explicitly warned that it'll happen, and that
hasn't happened yet. Up to this point, we've been using carrots rather
than sticks ;-) So it's a little way off.
Gerv
Gervase Markham
> Do we have a comprehensive MDC article on committing rules and
> responsibilities? I couldn't find one but seems like we should have.
> Wiki pages can show what changed since date X right?
That sounds like the right approach. You diff the page from when you
left to when you returned, and read the diffs.
Gerv
Mitchell Baker
ancient days) we had a lot of this on the /hacking page. but it's
wildly outdated, sorta embarrassingly so.
question is, who can / will write this?
mitchell
fantasai
> On Thu, Jun 4, 2009 at 5:15 PM, Mitchell Baker <mitc...@mozilla.com> wrote:
>> If an account has not been used for a year it may be shifted to a "dormant"
>> account.
>
> I think a year is too long here; I don't think we should be biasing
> towards the convenience of someone who commits every 8 months, and
> away from reducing our attack surface.
>
> Even 6 months is longer than I'd like, and I know that I'd bump into
> that limit relatively frequently! (Zak's previous thread was about
> just deleting the account, IIRC, not putting it into a
> more-easily-reverted dormant state, which is likely why there was more
> pushback on the timeframe.)
A year I can understand, but 6 months is too aggressive imho. You'll slice
off a lot of people who don't commit often, i.e. volunteers. And I don't
understand how that's going to reduce the attack surface. We haven't expired
any accounts since the start of the project more than a decade ago, right?
When was the last time we had a problem with someone who's already earned
commit rights maliciously "attacking" the repository? And how is requiring
an expired committer to request a refresh going to stop them if that's their
intent anyway?
Those aren't rhetorical questions, btw; if you're going to do this I want
some good justification here. I'm too stubborn not to jump through a few
extra hoops here, but I don't want to see other people turning away because
of excessive red tape.
~fantasai
Mike Shaver
> And I don't
> understand how that's going to reduce the attack surface. We haven't expired
> any accounts since the start of the project more than a decade ago, right?
We have, and for similar reasons. Those expiries were more complete,
too -- this is intended to be a "lightweight" model to make inactive
accounts less of a risk.
> When was the last time we had a problem with someone who's already earned
> commit rights maliciously "attacking" the repository?
It's not about the committer being malicious. It's about their
account being attacked because they forget they have it and so don't
change the email address on it correctly, or update their password
frequently, or report to us that the laptop with their ssh key on it
was compromised.
Mike
Gervase Markham
> Yes, this seems like something we should have. in the old days (well,
> ancient days) we had a lot of this on the /hacking page. but it's wildly
> outdated, sorta embarrassingly so.
>
> question is, who can / will write this?
I'd be happy to make a start, but I'll need comments and input from
those closer to the process than me.
Perhaps it could replace a lot of the verbiage currently in the sidebar
of Tinderbox:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox3.5
Gerv
Robert Kaiser
> On Sun, Jun 7, 2009 at 3:46 PM, fantasai<fantasa...@inkedblade.net> wrote:
>> And I don't
>> understand how that's going to reduce the attack surface. We haven't expired
>> any accounts since the start of the project more than a decade ago, right?
>
> We have, and for similar reasons. Those expiries were more complete,
> too -- this is intended to be a "lightweight" model to make inactive
> accounts less of a risk.
Those were a few cases, but not a common measure of any kind, AFAIK. We
have a large amount of open accounts out there that haven't been used in
years, I suspect.
>> When was the last time we had a problem with someone who's already earned
>> commit rights maliciously "attacking" the repository?
>
> It's not about the committer being malicious. It's about their
> account being attacked because they forget they have it and so don't
> change the email address on it correctly, or update their password
> frequently, or report to us that the laptop with their ssh key on it
> was compromised.
Sure. The fact is that we still haven't actually _seen_ such an attack
(and I hope we never will), so talking about reducing the attack surface
even more is IMHO not very helpful. Even if we make this one year right
now, we reduce the potential attack surface significantly. I'd rather
try and go for that for now and discuss further reducing it some time
down the road when we have have already gathered some experience with
the basic model of expiring, i.e. how often that happens with the "old"
limit. Once we have that in place, we'll probably have the technical
means easily to check how many people would be affected by making the
expiration period shorter, etc.
Robert Kaiser
Mitchell Baker
Gerv -- thanks, this sounds great. Maybe a link to the doc will go in
the tinderbox sidebar. or when it's done we can see if more of the
current text should be replaced. We can also link to it from the
Getting Commit Access Policy doc.
Probably interviewing a couple of people working with the new system
will get you most of the way. Let me know if no one volunteers and you
have trouble getting info, or if you'd like to talk more before you get
started.
thanks!
mitchell
Benjamin Smedberg
I have recently updated a lot of the content available from
https://developer.mozilla.org/En/Developer_Guide so that it is relatively up
to date. I'd like to propose that if there is an old /hacking page it should
redirect to the developer guide and we should improve that documentation
further if necessary.
I don't think that putting all these docs on one page for easy diffing is
going to be effective, though.
--BDS
Mitchell Baker
Benjamin
this is awesome. You are absolutely right the hacking page (which does
still exist) should point to this. At a quick glance I couldn't tell if
there is a bit about the try servers and such. It not, perhaps Gerv
should make sure that is included.
mitchell
Robert Kaiser
> I have recently updated a lot of the content available from
> https://developer.mozilla.org/En/Developer_Guide so that it is relatively up
> to date. I'd like to propose that if there is an old /hacking page it should
> redirect to the developer guide and we should improve that documentation
> further if necessary.
Could you file a bug against Websites::www.mozilla.org on that? We are
very happy on any pointer what parts can be removed from the actual site
content and redirected to better sources.
Robert Kaiser
Shawn Wilsher
> Sure. The fact is that we still haven't actually _seen_ such an attack
> (and I hope we never will), so talking about reducing the attack surface
> even more is IMHO not very helpful. Even if we make this one year right
> now, we reduce the potential attack surface significantly. I'd rather
> try and go for that for now and discuss further reducing it some time
> down the road when we have have already gathered some experience with
> the basic model of expiring, i.e. how often that happens with the "old"
> limit. Once we have that in place, we'll probably have the technical
> means easily to check how many people would be affected by making the
> expiration period shorter, etc.
"this security bug isn't important because we haven't seen an exploit in
the wild with it". We have had individual's bugzilla accounts
compromised who had access to security bugs. It doesn't feel like much
of a stretch to say an ssh key was lost/compromised.
Cheers,
Shawn
Boris Zbarsky
> That logic feels flawed, IMO. That feels like the same argument as
> "this security bug isn't important because we haven't seen an exploit in
> the wild with it". We have had individual's bugzilla accounts
> compromised who had access to security bugs. It doesn't feel like much
> of a stretch to say an ssh key was lost/compromised.
For what it's worth, we've also had developers' SSH keys
lost/compromised; they were just on top of things and let us know.
-Boris
Robert Kaiser
> That logic feels flawed, IMO. That feels like the same argument as "this
> security bug isn't important because we haven't seen an exploit in the
> wild with it". We have had individual's bugzilla accounts compromised
> who had access to security bugs. It doesn't feel like much of a stretch
> to say an ssh key was lost/compromised.
I didn't mean to imply that we shouldn't care. Whatever we go with, it's
always some sort of compromise when we treat an account as "abandoned"
or dormant. And technically, there's no reason to believe an account is
dangerous in any way when it's not been used for x months/years - OTOH,
every existing account has some risk of being compromised, no matter how
frequently it's being used or not (one can even easily find arguments
for the risk being higher on active accounts).
What we're doing here is risk management by determining where we set the
limit for an open account being more or less useful than risky.
In that way, I feel that your comparison with security bugs is somewhat
unfair, but I see the point you want to make with it.
The ultimate question we need to find a rule for is probably "what's the
criteria for determining if an account is useful enough to warrant the
inherent risk of it being open?"
The criteria like "inactive for a year" (or 6 months?) are just ideas
for finding a solution to that question.
Robert Kaiser