[gentoo-dev] About changing security policy to unCC maintainers when their are not needed

[gentoo-dev] About changing security policy to unCC maintainers when their are not needed

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

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 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed

[Jeroen Roovers]

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

[gentoo-dev] Re: About changing security policy to unCC maintainers when their are not needed

[Michael Palimaka]

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

Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed

[Rich Freeman]

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

Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]

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



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: About changing security policy to unCC maintainers when their are not needed

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

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



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

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



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: About changing security policy to unCC maintainers when their are not needed

[Sean Amoss]

[-- Attachment #1: Type: text/plain, Size: 3337 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed

[Jeroen Roovers]

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

Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed

[Ben de Groot]

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

Re: [gentoo-dev] Re: About changing security policy to unCC maintainers when their are not needed

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 3903 bytes --]

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

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: About changing security policy to unCC maintainers when their are not needed

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 3711 bytes --]

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

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed

[Alex Legler]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

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




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed

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

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

Re: [gentoo-dev] About changing security policy to unCC maintainers when their are not needed

[Alex Legler]

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

Re: [gentoo-dev] Re: About changing security policy to unCC maintainers when their are not needed

[Alex Legler]

[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Re: About changing security policy to unCC maintainers when their are not needed

[Rich Freeman]

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