Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   Security stabilisations (http://www.linux-archive.org/gentoo-development/400572-security-stabilisations.html)

Thilo Bangert 07-17-2010 02:21 PM

Security stabilisations
 
Christian Faulhammer <fauli@gentoo.org> said:
> Hi,
>
> please avoid having stabilisation requests
> like http://bugs.gentoo.org/show_bug.cgi?id=327877, blocking a
> security bug. That way, architecture teams may not see the severity
> directly and it slips, leaving users with vulnerable versions longer
> than needed. Thank you.

perhaps it's a good idea to tell people what you expect of them instead. i
presume just removing the blocker will not satisfy you.

;-)

kind regards
Thilo


>
> V-Li

Christian Faulhammer 07-17-2010 02:51 PM

Security stabilisations
 
Hi,

Thilo Bangert <bangert@gentoo.org>:
> > please avoid having stabilisation requests
> > like http://bugs.gentoo.org/show_bug.cgi?id=327877, blocking a
> > security bug. That way, architecture teams may not see the severity
> > directly and it slips, leaving users with vulnerable versions longer
> > than needed. Thank you.
>
> perhaps it's a good idea to tell people what you expect of them
> instead. i presume just removing the blocker will not satisfy you.

Do stabilisations on the security bug so arch team members can skim
through their stabilisation list by just looking for security@g.o to
find the vulnerable packages.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

Petteri Räty 07-17-2010 05:02 PM

Security stabilisations
 
On 07/17/2010 05:51 PM, Christian Faulhammer wrote:
> Hi,
>
> Thilo Bangert <bangert@gentoo.org>:
>>> please avoid having stabilisation requests
>>> like http://bugs.gentoo.org/show_bug.cgi?id=327877, blocking a
>>> security bug. That way, architecture teams may not see the severity
>>> directly and it slips, leaving users with vulnerable versions longer
>>> than needed. Thank you.
>>
>> perhaps it's a good idea to tell people what you expect of them
>> instead. i presume just removing the blocker will not satisfy you.
>
> Do stabilisations on the security bug so arch team members can skim
> through their stabilisation list by just looking for security@g.o to
> find the vulnerable packages.
>
> V-Li
>

If you want things to happen this way then it should be at least
documented in the devmanual.

Regards,
Petter

Matti Bickel 07-17-2010 05:50 PM

Security stabilisations
 
On 07/17/2010 07:02 PM, Petteri Räty wrote:
>> Do stabilisations on the security bug so arch team members can skim
>> through their stabilisation list by just looking for security@g.o to
>> find the vulnerable packages.
>>
>> V-Li
>>
>
> If you want things to happen this way then it should be at least
> documented in the devmanual.

It's in the security project's policy:
"once an ebuild is committed, evaluate what keywords are needed for the
fix ebuild and get arch-specific teams to test and mark the ebuild
stable on their architectures (arch-teams should be cc'd on the bug, as
well as releng during release preparation) and set status whiteboard to
stable"
http://www.gentoo.org/security/en/vulnerability-policy.xml, Chapter 4

As the CC'ing should be done by the security folks/the maintainer when a
new ebuild is ready, I don't think it needs to be in devmanual. The
relevant people should be aware of the process.

Petteri Räty 07-17-2010 05:58 PM

Security stabilisations
 
On 07/17/2010 08:50 PM, Matti Bickel wrote:
> On 07/17/2010 07:02 PM, Petteri Räty wrote:
>>> Do stabilisations on the security bug so arch team members can skim
>>> through their stabilisation list by just looking for security@g.o to
>>> find the vulnerable packages.
>>>
>>> V-Li
>>>
>>
>> If you want things to happen this way then it should be at least
>> documented in the devmanual.
>
> It's in the security project's policy:
> "once an ebuild is committed, evaluate what keywords are needed for the
> fix ebuild and get arch-specific teams to test and mark the ebuild
> stable on their architectures (arch-teams should be cc'd on the bug, as
> well as releng during release preparation) and set status whiteboard to
> stable"
> http://www.gentoo.org/security/en/vulnerability-policy.xml, Chapter 4
>
> As the CC'ing should be done by the security folks/the maintainer when a
> new ebuild is ready, I don't think it needs to be in devmanual. The
> relevant people should be aware of the process.
>

If relevant people already know the policy and act accordingly then why
do we have this thread in the first place?

Regards,
Petteri

Matti Bickel 07-17-2010 06:09 PM

Security stabilisations
 
On 07/17/2010 07:58 PM, Petteri Räty wrote:
>> As the CC'ing should be done by the security folks/the maintainer when a
>> new ebuild is ready, I don't think it needs to be in devmanual. The
>> relevant people should be aware of the process.
>>
> If relevant people already know the policy and act accordingly then why
> do we have this thread in the first place?

Dunno, I take it as a friendly reminder. People can slip up.

Christian Faulhammer 07-18-2010 06:02 AM

Security stabilisations
 
Hi,

Petteri Räty <betelgeuse@gentoo.org>:
> If relevant people already know the policy and act accordingly then
> why do we have this thread in the first place?

Security is (as all the teams), badly understaffed, so sometimes
something like this slips. It was a friendly reminder as it happens
from time to time and slipping security bugs is the worst that can
happen from an arch perspective.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>


All times are GMT. The time now is 12:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.