Re: [gentoo-dev] Re: 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 a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: About changing security policy to unCC maintainers when their are not needed
On Fri, Sep 14, 2012 at 7:15 AM, Alex Legler a...@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
Re: [gentoo-dev] Re: 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. :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 :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: 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. :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 signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: 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
Re: [gentoo-dev] Re: 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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: 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 signature.asc Description: OpenPGP digital signature
