[gentoo-dev] Re: Developer Retirements
Doug Goldstein posted eafa4c130903101013s3bb64404g9e65ca0fc8973...@mail.gmail.com, excerpted below, on Tue, 10 Mar 2009 12:13:36 -0500: > So really an effective solution might be for the recruiters/retirement > staff to change a user's shell with a script that spits out a message > that says something to the effect of: > > "You have been inactive for a while. Please contact recruiters to > re-enable your account. This was done as a security measure." > > Obviously a little friendlier would be better but everyone gets the > gist. That'll prevent them from logging into infra boxes and from being > able to do a commit. That does seem to take care of the security side (assuming the cracker can't simply contact recruiters and get reenabled, no verification), yes. That's my biggest concern. However, upon reading rane's replies, his point that if retaking the quizes is hard, they probably DO need the refresh, makes a lot of sense to me as well. But even tho the knowledge aspect applies to every returning dev while the security aspect above is (hopefully) low chance, lack of up-to-date tech and policy knowledge (as addressed by the quizes) at worst breaks a tree for a few hours or a package for perhaps a few months. If Gentoo devs as a group are willing to live with that, so am I as a Gentoo user and Gentoo system sysadmin. It's thus an entirely different level of discussion than that of a relatively lower chance but much higher damage potential security breach, which every Gentoo user (aka Gentoo system sysadmin) therefore has an interest in. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: Developer Retirements
2009/3/10 Doug Goldstein : > So really an effective solution might be for the recruiters/retirement staff > to change a user's shell with a script that spits out a message that says > something to the effect of: > > "You have been inactive for a while. Please contact recruiters to re-enable > your account. This was done as a security measure." > > Obviously a little friendlier would be better but everyone gets the gist. > That'll prevent them from logging into infra boxes and from being able to do > a commit. > First of all there's been a lot of returning devs from whom I heard no word of complaint about the procedure. Bonsaikitten is one of them if this argument really requires an example. Now, if someone can't, has no time or is unwilling to redo his quiz... what makes you think this person will make a good developer later on? What will ensure quality of his contributions? After months or (in most cases) years of not being a developer it's very likely the person is out of touch with most current things in Gentoo and a conversation with a recruiter may be really good learning experience. I heard multiple times from recruiters that this is procedure is necessary for returning developers. If you ask them, I'm sure they will confirm those devs often need such refreshing and also are appreciating the time put into it from the recruiting team. Finally, what you are proposing (which I read as infra suspending their access automatically instead of me or other undertaker contacting the person first) far harsher and putting off than pretty soft (and many say too soft) procedures we have now. I personally would prefer to talk to such a person before suspending them anything happens. Please also remember that if we suspend access automatically and it's suspended for some time, it will require jumping through hoops upon returning just like one has to jump through them when being recruited back. I don't think QA will allow us to just give access back without prior checking if the person is current with everything a developer should know. And if they did allow that, I wouldn't consider this a good thing. Kind regards, Lukasz Damentko
Re: [gentoo-dev] Re: Developer Retirements
On Tue, Mar 10, 2009 at 8:35 AM, Duncan <1i5t5.dun...@cox.net> wrote: > "Pierre-Yves Rofes" posted > a4345526fd26a2a6f5dd3cccb4e9767d.squir...@mail.rofes.fr, excerpted below, > on Tue, 10 Mar 2009 11:21:55 +0100: > > >> We don't want some still active authorization and key > >> from two years ago getting stolen and used to try to slip a bad commit > >> under the radar [...] > > > > With some devs reviewing gentoo-commits@, I highly doubt that this > > commit could go unnoticed more than a few hours. > > That's a relatively new and very good change, and may indeed change the > thinking on this one, some. But why even risk that when (as rane just > posted) there's all deliberate effort to contact on the way out and a > fast return, for someone who hasn't put an away up, has ignored the > contact efforts or after being contacted said yes, retire me, and who > hasn't had any commits in months already, with no indication that's going > to change. > > Can you imagine the PR on even a few hours' breach, when it turns out > they'd been inactive for years, but their login was still active? Would > you want it to be /your/ machines affected? > > Yes, it can happen with even active devs, but the risk is considered > worth it there. But devs that have been inactive for months or years, > and who have ignored contacts or even asked to be retired after the > contact? IMO that's needless risk, (almost) entirely down-side (with > "almost" in there only as a CYA on an otherwise absolute "entirely"), > especially when reuptake is (as posted) so fast. > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman > > > So really an effective solution might be for the recruiters/retirement staff to change a user's shell with a script that spits out a message that says something to the effect of: "You have been inactive for a while. Please contact recruiters to re-enable your account. This was done as a security measure." Obviously a little friendlier would be better but everyone gets the gist. That'll prevent them from logging into infra boxes and from being able to do a commit.
Re: [gentoo-dev] Re: Developer Retirements
On Tuesday 10 of March 2009 16:29:56 Alec Warner wrote: > > With some devs reviewing gentoo-commits@, I highly doubt that this commit > > could go unnoticed more than a few hours. > really? cause I bet I could slip something in; now I'm motivated to try ;p I somewhat share the view that's rather easy to slip some parts in stream of commits. Would it be possible to introduce some kind of *commit*/*ebuild* *reviewing* *system*? So that every change to tree would need to be somewhat approved by anyone else - just to provide extra pair of eyes to catch early some silly, obvious, unnecessary or very tricky parts of code. It could be quite cheap to introduce and yet not-demotivating step to increase overall quality. I bet it's a practice already by some developers but it would be nice if it could be introduced as a rule for everyone (possibly requiring some GLEP). Personally I don't find it at all humiliating if someone is capable of QA my code - I actually very appreciate it, and I guess most developers do. Should I start separate thread? -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Developer Retirements
On Tue, Mar 10, 2009 at 3:21 AM, Pierre-Yves Rofes wrote: > On Tue, March 10, 2009 7:07 am, Duncan wrote: >> Gordon Malm posted >> 200903091617.48682.gen...@gentoo.org, excerpted below, on Mon, 09 Mar >> 2009 16:17:48 -0700: >> >>> There is an important security aspect to retiring folks - commit >>> abilities. Perhaps in the case a dev wants to contribute but cannot in >>> the near future their commit privs can just be revoked until such time >>> they ask for them to be turned back on? I guess that would be an >>> 'extended devaway' ? >> > > [...] > >> We don't want some still active authorization and key >> from two years ago getting stolen and used to try to slip a bad commit >> under the radar [...] > > With some devs reviewing gentoo-commits@, I highly doubt that this commit > could go unnoticed more than a few hours. really? cause I bet I could slip something in; now I'm motivated to try ;p > > -- > Pierre-Yves Rofes > Gentoo Linux Security Team > > > > >
[gentoo-dev] Re: Developer Retirements
"Pierre-Yves Rofes" posted a4345526fd26a2a6f5dd3cccb4e9767d.squir...@mail.rofes.fr, excerpted below, on Tue, 10 Mar 2009 11:21:55 +0100: >> We don't want some still active authorization and key >> from two years ago getting stolen and used to try to slip a bad commit >> under the radar [...] > > With some devs reviewing gentoo-commits@, I highly doubt that this > commit could go unnoticed more than a few hours. That's a relatively new and very good change, and may indeed change the thinking on this one, some. But why even risk that when (as rane just posted) there's all deliberate effort to contact on the way out and a fast return, for someone who hasn't put an away up, has ignored the contact efforts or after being contacted said yes, retire me, and who hasn't had any commits in months already, with no indication that's going to change. Can you imagine the PR on even a few hours' breach, when it turns out they'd been inactive for years, but their login was still active? Would you want it to be /your/ machines affected? Yes, it can happen with even active devs, but the risk is considered worth it there. But devs that have been inactive for months or years, and who have ignored contacts or even asked to be retired after the contact? IMO that's needless risk, (almost) entirely down-side (with "almost" in there only as a CYA on an otherwise absolute "entirely"), especially when reuptake is (as posted) so fast. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: Developer Retirements
On Tue, March 10, 2009 7:07 am, Duncan wrote: > Gordon Malm posted > 200903091617.48682.gen...@gentoo.org, excerpted below, on Mon, 09 Mar > 2009 16:17:48 -0700: > >> There is an important security aspect to retiring folks - commit >> abilities. Perhaps in the case a dev wants to contribute but cannot in >> the near future their commit privs can just be revoked until such time >> they ask for them to be turned back on? I guess that would be an >> 'extended devaway' ? > [...] > We don't want some still active authorization and key > from two years ago getting stolen and used to try to slip a bad commit > under the radar [...] With some devs reviewing gentoo-commits@, I highly doubt that this commit could go unnoticed more than a few hours. -- Pierre-Yves Rofes Gentoo Linux Security Team
[gentoo-dev] Re: Developer Retirements
Gordon Malm posted 200903091617.48682.gen...@gentoo.org, excerpted below, on Mon, 09 Mar 2009 16:17:48 -0700: > There is an important security aspect to retiring folks - commit > abilities. Perhaps in the case a dev wants to contribute but cannot in > the near future their commit privs can just be revoked until such time > they ask for them to be turned back on? I guess that would be an > 'extended devaway' ? This is my concern, and one that infra has expressed on occasions when the topic has come up before. On principle, a stale yet still active authorization is an authorization just begging to have some cracker stumble on it. We don't want some still active authorization and key from two years ago getting stolen and used to try to slip a bad commit under the radar, where the dev won't have a clue as he's not been active for years and has forgotten the key was even stashed somewhere /to/ get stolen. The six-month retirement thing is a backstop to prevent things like that from occurring. Maybe an extended "dev-away" mechanism, whereby the dev just needs to notify devrel that he's going active again (preferably in- person or with some inside joke or other verifiable mechanism so it's demonstrably /not/ some cracker simply finding the key), could be preferred to the whole inboarding, mentoring, etc, process all over again. Then again, a lot can change in two years. The former dev may not know about the new EAPIs and other policy and etc. changes, and having taken the quiz and gone thru the process before, it should be easier the second time and could be expedited, but there's an argument for still going thru it, just to start off again on the right foot, as they say. Also, that time would serve as an intro period between the returning dev and new ones that have come in since his retirement. So yeah, maybe a somewhat abridged inboarding is appropriate for a returning dev, but eliminating it entirely, as an extended dev-away, might be going too far. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
