FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-13-2012, 07:29 AM
Pacho Ramos
 
Default About changing security policy to unCC maintainers when their are not needed

El mié, 12-09-2012 a las 18:30 -0400, Sean Amoss escribió:
> On 09/12/2012 02:54 PM, Pacho Ramos wrote:
> > El jue, 13-09-2012 a las 04:30 +1000, Michael Palimaka escribió:
> >> On 2012-09-13 03:59, Pacho Ramos wrote:
> >>> Hello
> >>>
> >>> Currently, package maintainers are CCed to security bugs when their are
> >>> needed. The problem is that, once maintainers add a fixed version and
> >>> tell security team they are ok to get it stabilized, maintainers are
> >>> kept CCed until bug is closed by security team. This usually means
> >>> getting a lot of mail after some time when security team discuss if a
> >>> GLSA should be filled or not, if security bot adds some comment... some
> >>> of that comments are applied to really old bugs that need no action from
> >>> maintainers.
> >>>
>
> Our discussion is very minimal. There will typically never be any more
> than 3 comments discussing whether to have a GLSA or not -- in the event
> that 2 security team members disagree and a 3rd has to break the tie.
>
> Some bugs have been receiving more spam than usual (lately, from
> GLSAMaker/CVETool bot) as we have been trying to clean-up old CVE
> entries in the tool and old bugs.
>
> It would be nice if maintainers would follow-up on security bugs in
> [upstream], [ebuild], [stable], and [cleanup] to get those bugs closed
> as soon as possible. You are welcome to join the security team to help
> us keep bugs up-to-date and work on the backlog of GLSAs.
>
> >>> Maybe would be interesting to change the policy to unCC maintainers
> >>> again when their action is no longer required.
> >>>
> >>> What do you think?
> >>>
> >>> Thanks for your thoughts
> >>>
> >>
> >> Hello,
> >>
> >> Is the policy you describe officially documented, or just current
> behaviour?
> >>
> >
> > I don't know, at least it's the current behavior, but I don't know if
> > it's a policy :/
>
> Yes, this is part of the Vulnerability Treatment Policy [1], listed
> under the "Security Bug Wrangler role" in Chapter 3.
>
> >
> >> In KDE and Qt herds for example, we usually just unCC ourselves when
> >> we've taken the required action.
> >>
> >> Best regards,
> >> Michael
> >>
>
> The security bug process [2] involves removing the vulnerable versions
> from the tree after all arches are finished stabilizing. This is to
> ensure that users do not accidentally install vulnerable software. Many
> maintainers do not do this and I think that all of us on the security
> team are guilty of not always following up to ensure the vulnerable
> versions are dropped. As Jeroen mentioned, how will maintainers know
> when to remove the vulnerable versions if they are not current on the bug?
>
> If stabilization is complete and the maintainers have removed vulnerable
> versions from the tree, there is typically no issue with unCC'ing
> themselves like KDE/Qt herds do.
>
> Arches sometimes run into minor issues that don't warrant opening a new
> bug - they should be able to get help from maintainers without re-CC'ing
> them.
>
> If a decision were made to unCC maintainers, there would probably be
> some maintainers/herds that want to be left on the CC list and the
> security team does not have the capacity right now to keep up with
> exceptions.
>
> (Strictly my opinions, not that of the whole security team)
>
>
> [1] http://www.gentoo.org/security/en/vulnerability-policy.xml#doc_chap3
> [2] http://www.gentoo.org/security/en/coordinator_guide.xml#doc_chap3
>
>

OK, then, looks like the policy could be that, once all arches are done,
maintainers cleanup ebuilds and unCC themselves, that way, if they are
still getting mails from bug report is because they forgot to remove
vulnerable versions and, if not, is because all their work was finished.
Are you ok with this policy?

Thanks
 
Old 09-13-2012, 07:30 AM
Pacho Ramos
 
Default About changing security policy to unCC maintainers when their are not needed

El mié, 12-09-2012 a las 18:30 -0400, Sean Amoss escribió:
> On 09/12/2012 02:54 PM, Pacho Ramos wrote:
> > El jue, 13-09-2012 a las 04:30 +1000, Michael Palimaka escribió:
> >> On 2012-09-13 03:59, Pacho Ramos wrote:
> >>> Hello
> >>>
> >>> Currently, package maintainers are CCed to security bugs when their are
> >>> needed. The problem is that, once maintainers add a fixed version and
> >>> tell security team they are ok to get it stabilized, maintainers are
> >>> kept CCed until bug is closed by security team. This usually means
> >>> getting a lot of mail after some time when security team discuss if a
> >>> GLSA should be filled or not, if security bot adds some comment... some
> >>> of that comments are applied to really old bugs that need no action from
> >>> maintainers.
> >>>
>
> Our discussion is very minimal. There will typically never be any more
> than 3 comments discussing whether to have a GLSA or not -- in the event
> that 2 security team members disagree and a 3rd has to break the tie.
>
> Some bugs have been receiving more spam than usual (lately, from
> GLSAMaker/CVETool bot) as we have been trying to clean-up old CVE
> entries in the tool and old bugs.
>
> It would be nice if maintainers would follow-up on security bugs in
> [upstream], [ebuild], [stable], and [cleanup] to get those bugs closed
> as soon as possible. You are welcome to join the security team to help
> us keep bugs up-to-date and work on the backlog of GLSAs.
>
> >>> Maybe would be interesting to change the policy to unCC maintainers
> >>> again when their action is no longer required.
> >>>
> >>> What do you think?
> >>>
> >>> Thanks for your thoughts
> >>>
> >>
> >> Hello,
> >>
> >> Is the policy you describe officially documented, or just current
> behaviour?
> >>
> >
> > I don't know, at least it's the current behavior, but I don't know if
> > it's a policy :/
>
> Yes, this is part of the Vulnerability Treatment Policy [1], listed
> under the "Security Bug Wrangler role" in Chapter 3.
>
> >
> >> In KDE and Qt herds for example, we usually just unCC ourselves when
> >> we've taken the required action.
> >>
> >> Best regards,
> >> Michael
> >>
>
> The security bug process [2] involves removing the vulnerable versions
> from the tree after all arches are finished stabilizing. This is to
> ensure that users do not accidentally install vulnerable software. Many
> maintainers do not do this and I think that all of us on the security
> team are guilty of not always following up to ensure the vulnerable
> versions are dropped. As Jeroen mentioned, how will maintainers know
> when to remove the vulnerable versions if they are not current on the bug?
>
> If stabilization is complete and the maintainers have removed vulnerable
> versions from the tree, there is typically no issue with unCC'ing
> themselves like KDE/Qt herds do.
>
> Arches sometimes run into minor issues that don't warrant opening a new
> bug - they should be able to get help from maintainers without re-CC'ing
> them.
>
> If a decision were made to unCC maintainers, there would probably be
> some maintainers/herds that want to be left on the CC list and the
> security team does not have the capacity right now to keep up with
> exceptions.
>
> (Strictly my opinions, not that of the whole security team)
>
>
> [1] http://www.gentoo.org/security/en/vulnerability-policy.xml#doc_chap3
> [2] http://www.gentoo.org/security/en/coordinator_guide.xml#doc_chap3
>
>

Regarding joining to security team, I have considered a lot of time that
option... but I clearly don't have enough time this days :|, sorry
 
Old 09-13-2012, 07:32 AM
Pacho Ramos
 
Default About changing security policy to unCC maintainers when their are not needed

El jue, 13-09-2012 a las 03:43 +0200, Jeroen Roovers escribió:
> On Wed, 12 Sep 2012 20:53:20 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
>
> > > You can un-CC yourself. I don't see why security@ should be doing
> > > the legwork.
> >
> > It shouldn't be so hard to do, they can do it just when they CC
> > arches, instead of relaying some random team member to do it himself
> > once a useless message is received
>
> It does become a chore when you have to check a list to match various
> CC'd people's preferences and decide whether to un-CC them based on
> that, the way they were CC'd (did they do it themselves, were they CC'd
> by security, and so on) and perhaps some other factors someone will no
> doubt soon propose in this thread.
>
> Basically you are saying, "why doesn't anyone else do my volunteer work
> for me".
>
>
> jer
>
>

I am not saying that, you can see who CCed them in history and most of
times was security team who CCed them... anyway, per my just replied
mail to Sean, I think we could reach a good compromise. What I don't
understand is why you think I am trying to say that thing when I ever
wasn't sure if maintainers were allowed to unCC themselves when they
think
 
Old 09-13-2012, 01:48 PM
Alex Legler
 
Default About changing security policy to unCC maintainers when their are not needed

On 12.09.2012 19:59, Pacho Ramos wrote:
> Hello
>
> Currently, package maintainers are CCed to security bugs when their are
> needed. The problem is that, once maintainers add a fixed version and
> tell security team they are ok to get it stabilized, maintainers are
> kept CCed until bug is closed by security team. This usually means
> getting a lot of mail after some time when security team discuss if a
> GLSA should be filled or not, if security bot adds some comment... some
> of that comments are applied to really old bugs that need no action from
> maintainers.
>
> Maybe would be interesting to change the policy to unCC maintainers
> again when their action is no longer required.
>
> What do you think?

Sorta OT but a general thing: I think you should CC teams you want to
talk to and not only use the gentoo-systemd-flamewars^W^W-dev mailing
list where these teams might only find your post by chance.

>
> Thanks for your thoughts
>
--
Alex Legler <a3li@gentoo.org>
Gentoo Security/Ruby/Infrastructure
 
Old 09-13-2012, 07:57 PM
Pacho Ramos
 
Default About changing security policy to unCC maintainers when their are not needed

El jue, 13-09-2012 a las 15:48 +0200, Alex Legler escribió:
> On 12.09.2012 19:59, Pacho Ramos wrote:
> > Hello
> >
> > Currently, package maintainers are CCed to security bugs when their are
> > needed. The problem is that, once maintainers add a fixed version and
> > tell security team they are ok to get it stabilized, maintainers are
> > kept CCed until bug is closed by security team. This usually means
> > getting a lot of mail after some time when security team discuss if a
> > GLSA should be filled or not, if security bot adds some comment... some
> > of that comments are applied to really old bugs that need no action from
> > maintainers.
> >
> > Maybe would be interesting to change the policy to unCC maintainers
> > again when their action is no longer required.
> >
> > What do you think?
>
> Sorta OT but a general thing: I think you should CC teams you want to
> talk to and not only use the gentoo-systemd-flamewars^W^W-dev mailing
> list where these teams might only find your post by chance.
>
> >
> > Thanks for your thoughts
> >

I thought all developers were subscribed to gentoo-dev and would read
it :|
 
Old 09-13-2012, 08:11 PM
Rich Freeman
 
Default About changing security policy to unCC maintainers when their are not needed

On Thu, Sep 13, 2012 at 3:57 PM, Pacho Ramos <pacho@gentoo.org> wrote:
> El jue, 13-09-2012 a las 15:48 +0200, Alex Legler escribió:
>> Sorta OT but a general thing: I think you should CC teams you want to
>> talk to and not only use the gentoo-systemd-flamewars^W^W-dev mailing
>> list where these teams might only find your post by chance.
>>
>
> I thought all developers were subscribed to gentoo-dev and would read
> it :|
>

Maybe, maybe not, but this seems like the appropriate place to discuss
it. Maybe -project instead. However, I don't think you need to CC 14
teams on an email just in case they don't read -dev. Debate it on
-dev, and then announce the outcome on -announce if it is important
enough.

Rich
 
Old 09-14-2012, 09:34 AM
Alex Legler
 
Default About changing security policy to unCC maintainers when their are not needed

Am 2012-09-13 22:11, schrieb Rich Freeman:
On Thu, Sep 13, 2012 at 3:57 PM, Pacho Ramos <pacho@gentoo.org>
wrote:

El jue, 13-09-2012 a las 15:48 +0200, Alex Legler escribió:
Sorta OT but a general thing: I think you should CC teams you want
to
talk to and not only use the gentoo-systemd-flamewars^W^W-dev
mailing

list where these teams might only find your post by chance.



I thought all developers were subscribed to gentoo-dev and would
read

it :|



No. -dev is not mandatory and several people are explicitly not
subscribed,
others don't read it regularly. Given the low SNR this list currently
has,

that's not really a surprise.



Maybe, maybe not, but this seems like the appropriate place to
discuss
it. Maybe -project instead. However, I don't think you need to CC
14

teams on an email just in case they don't read -dev. Debate it on
-dev, and then announce the outcome on -announce if it is important
enough.


Don't be silly. This is not about 14 teams, it pertains mainly one
team.

CCing one alias is not too much to ask for, given people CC aliases all
the time even for simpler things than this.
Also, I'd like to be asked before *you* change things in *my* team's
policy. (Think someone touching others' ebuilds, all hell would break
loose)

So: Discuss with the team (on -dev *if* they read it), then announce
on -dev-announce.
We read it fairly soon this time, but please don't expect everyone is
actively

filtering the traffic on this list for things that pertain to them.
There are team aliases for a reason.



Rich


--
Alex Legler <a3li@gentoo.org>
Gentoo Security/Ruby/Infrastructure
 
Old 09-14-2012, 11:15 AM
Alex Legler
 
Default About changing security policy to unCC maintainers when their are not needed

On 13.09.2012 09:29, Pacho Ramos wrote:
> […]
> OK, then, looks like the policy could be that, once all arches are done,
> maintainers cleanup ebuilds and unCC themselves, that way, if they are
> still getting mails from bug report is because they forgot to remove
> vulnerable versions and, if not, is because all their work was finished.
> Are you ok with this policy?

A general note: The request makes one wonder a bit how much you actually
care about your package if a few emails disturb you. Arches, Security,
and users reporting issues are trying to help you get the package into a
good shape.

Now, I can understand the request for the sake of possibly less email,
less bugs appearing in "bugs I'm in CC on" searches and such, especially
when things on the security side take a bit longer.

We have no problem with people removing themselves after a bit of time,
after arches are done and vulnerable versions are removed, but I
certainly won't encourage people to do that actively right away.
The reasons for this are a) that unCC usually generates another email
(hey, not just maintainers want as little email as possible) and b)
sometimes things still come up that require maintainer attention (mostly
users reporting issues).
The Security team certainly won't unCC people as suggested before in the
thread, and if there are packages where more issues happen "post-unCC",
we'd have to manually reCC maintainers every time. So you'd weigh up our
time with a few bytes in your inbox.

What we could agree on is clarifying that maintainers have to stay on CC
until stabling is done and vulnerable versions are removed, they can, if
they want, remove themselves after a bit of time after that, and that
Security might ask them to stay on CC next time, should the package turn
out to require their attention after stabling more often.

@security: ack?

Alex

--
Alex Legler <a3li@gentoo.org>
Gentoo Security/Ruby/Infrastructure
 
Old 09-14-2012, 11:33 AM
Rich Freeman
 
Default About changing security policy to unCC maintainers when their are not needed

On Fri, Sep 14, 2012 at 7:15 AM, Alex Legler <a3li@gentoo.org> wrote:
> A general note: The request makes one wonder a bit how much you actually
> care about your package if a few emails disturb you. Arches, Security,
> and users reporting issues are trying to help you get the package into a
> good shape.

I suspect that this concern arose in part due to a series of around
two dozen bug comment emails that were sent to the chromium@ alias in
the span of a day relating to security problems for versions as old as
chromium-7. I doubt anybody anywhere still cares about security
problems with chromium 7 - just about every major chromium release
contains security fixes, so if you aren't on the latest major version
you're guaranteed to be vulnerable. A good tip is that if you haven't
worked out your CPUs in the last two weeks on a chromium build, you're
out of date.

I suspect this is a bit of a one-off as the security team continues to
catch up from a past hiatus (stabilizations were getting done, but
GLSAs were never issued). I remember there being a wave of ancient
GLSAs a few months ago, but perhaps the entire queue wasn't flushed
out. Aliases that pertain to a large number of security-affected
packages were probably disproportionately impacted.

So, if this is a one-off then perhaps we shouldn't use it as the basis
for policy changes. That said, I think your proposal to allow
maintainers to un-CC themselves after the tree is cleaned up makes
sense.

Rich
 

Thread Tools




All times are GMT. The time now is 04:27 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org