About changing security policy to unCC maintainers when their are not needed
 

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?

Thanks for your thoughts

About changing security policy to unCC maintainers when their are not needed
 

On Wed, 12 Sep 2012 19:59:01 +0200
Pacho Ramos <pacho@gentoo.org> 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.

So you would want to be re-CC'd when it is time to remove the vulnerable
versions, I guess.

Also, I have problems with stating "getting too much mail" as the
actual problem. Perhaps your brain or your computer can smartly filter
them out?

> Maybe would be interesting to change the policy to unCC maintainers
> again when their action is no longer required.

You can un-CC yourself. I don't see why security@ should be doing the
legwork.


jer

About changing security policy to unCC maintainers when their are not needed
 

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.

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?

In KDE and Qt herds for example, we usually just unCC ourselves when
we've taken the required action.


Best regards,
Michael

About changing security policy to unCC maintainers when their are not needed
 

On Wed, Sep 12, 2012 at 2:29 PM, Jeroen Roovers <jer@gentoo.org> wrote:
>
> So you would want to be re-CC'd when it is time to remove the vulnerable
> versions, I guess.

Isn't this done shortly after keywording is complete? I think the
concern is more about issuing GLSAs/etc, which apparently can happen
months or years after the vulnerable versions were removed judging by
recent chromium@ mail.

> You can un-CC yourself. I don't see why security@ should be doing the
> legwork.

I see no issue with that.

Rich

About changing security policy to unCC maintainers when their are not needed
 

El mié, 12-09-2012 a las 20:29 +0200, Jeroen Roovers escribió:
> On Wed, 12 Sep 2012 19:59:01 +0200
> Pacho Ramos <pacho@gentoo.org> 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.
>
> So you would want to be re-CC'd when it is time to remove the vulnerable
> versions, I guess.

Personally, I have never been asked by them to remove old vulnerable
versions (and this refers to bugs I get from gnome and dotnet herds)

>
> Also, I have problems with stating "getting too much mail" as the
> actual problem.

The problem is that one and, also, getting a comment months after the
fixed version was stabilized with a comment like "GLSA vote = no" or
similar. That comment is only useful to security team.

> Perhaps your brain or your computer can smartly filter
> them out?

Perhaps things can be enhanced to not send useless mails that will need
to get removed just after they are get, this is pretty annoying when I
fetch a ton of mails after being out during August.

>
> > Maybe would be interesting to change the policy to unCC maintainers
> > again when their action is no longer required.
>
> 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

> jer
>
>

About changing security policy to unCC maintainers when their are not needed
 

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.
> >
> > 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 :/

> In KDE and Qt herds for example, we usually just unCC ourselves when
> we've taken the required action.
>
> Best regards,
> Michael
>
>
>

About changing security policy to unCC maintainers when their are not needed
 

El mié, 12-09-2012 a las 14:42 -0400, Rich Freeman escribió:
> On Wed, Sep 12, 2012 at 2:29 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> >
> > So you would want to be re-CC'd when it is time to remove the vulnerable
> > versions, I guess.
>
> Isn't this done shortly after keywording is complete? I think the
> concern is more about issuing GLSAs/etc, which apparently can happen
> months or years after the vulnerable versions were removed judging by
> recent chromium@ mail.
>

Yes, I am referring to that GLSA messages that are received months later
and are useless to maintainers

> > You can un-CC yourself. I don't see why security@ should be doing the
> > legwork.
>
> I see no issue with that.
>
> Rich
>
>

About changing security policy to unCC maintainers when their are not needed
 

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. :D

>>> 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

About changing security policy to unCC maintainers when their are not needed
 

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

About changing security policy to unCC maintainers when their are not needed
 

On 13 September 2012 09:43, Jeroen Roovers <jer@gentoo.org> wrote:
> 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 don't mind getting the odd security bug mail. It's relatively low
volume, and I like to know what's happening to packages I maintain.

What irks me much more is that it can take half an eternity for
security bugs to get addressed properly. Especially minor arches can
stretch out the stabilization process for months or years. Recently we
(Qt team) had to push really hard and "punish" lagging minor arches
with hard-masking Qt libs and all reverse dependencies in order to get
an ancient version with several open security bugs removed from the
tree (because they hadn't keyworded/stabilized newer versions and were
unresponsive to our requests).

I think we should adopt a policy that we set a hard limit of 3 months
in which arches can address stabilization requests before we just drop
keywords. Even that is in my opinion an awfully long time to leave
vulnerable versions in the tree.

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin