Welcome

[Dennis Gilmore]

So where do we start?

I guess a good point is to refer everyone to 
http://fedoraproject.org/wiki/Extras/Schedule/SecurityPolicy  and get some 
discussion going on that

-- 
Regards

Dennis Gilmore,  RHCE
Proud Australian

[Josh Bressers]

>  So where do we start?
>  
>  I guess a good point is to refer everyone to 
>  http://fedoraproject.org/wiki/Extras/Schedule/SecurityPolicy  and get some 
>  discussion going on that 
I've looked that document over in the past.  I admit the times at the end
chart scare me.  That's a fairly complicated chart.  Within Red Hat there
was discussion about how to best classify security issues, this is what we
came up with:
http://www.redhat.com/security/updates/classification/

When one has to classify security threats, less is more.

I would suggest something more along these lines:

Critical: Don't bother waiting for the maintainer, do whatever it takes to
    fix it.
Important: A few days.
Moderate: A few weeks.
Low: A few months.

-- 
    JB

[Jesse Keating]

On Thu, 2006-03-02 at 16:24 -0500, Josh Bressers wrote:
>  Critical: Don't bother waiting for the maintainer, do whatever it
> takes to
>      fix it.
>  Important: A few days.
>  Moderate: A few weeks.
>  Low: A few months.  
I like this too.  Anything to simplify.  Within Legacy we tried ot make
things way too complicated to begin with.  Over time we've adopted much
more simple processes and continue to do so.  As Legacy adopts more
Extras like infrastructure, it would make sense for Extras and Legacy to
collaborate on security policies.  One applies to Core packages in EOL
releases (Legacy) the other applies to Extras packages in general.

-- 
Jesse Keating
Release Engineer: Fedora

[Jason L Tibbitts III]

> >>>> "JB" == Josh Bressers
> <bressers(a)redhat.com&gt; writes: 
JB> I've looked that document over in the past.  I admit the times at
JB> the end chart scare me.

I agree.  The idea was to have a few guidelines so that we weren't
accused of being arbitrary, but it sort of grew beyond reason.
Anyway, it's just a draft.

JB> Critical: Don't bother waiting for the maintainer, do whatever it
JB> takes to fix it.

That's a huge amount of power to grant a security team for a project
like Extras.  But also, it would imply certain things about the Extras
security team that we don't really want to imply.  Most importantly,
we don't want anyone getting the idea that it is our job to fix
security problems.  It's not; that falls to the maintainer.  The
security team exists (or would exist, under the current proposal) to
assist maintainers and only to step in an emergency when the
maintainer is inactive or if the maintainer requests assistance.

That's why we propose waiting a minimum of 24 hours before waiting to
hear from a maintainer.  Sure, if we have a patch we'd attach it to
the bug, just the same as anyone else could.  But we wouldn't actualy
step in and do anything until the prescribed waiting period was up.

 - J<

[Josh Bressers]

>  
>  I like this too.  Anything to simplify.  Within Legacy we tried ot make
>  things way too complicated to begin with.  Over time we've adopted much
>  more simple processes and continue to do so.  As Legacy adopts more
>  Extras like infrastructure, it would make sense for Extras and Legacy to
>  collaborate on security policies.  One applies to Core packages in EOL
>  releases (Legacy) the other applies to Extras packages in general. 
This also brings up the question of how do we want to (if at all) have
Legacy and Extras security teams work together.  There probably won't be
much overlap, but often the analysis is the most important part of dealing
with security issues.

-- 
    JB

[Jesse Keating]

On Thu, 2006-03-02 at 16:34 -0500, Josh Bressers wrote:
>  This also brings up the question of how do we want to (if at all)
> have
>  Legacy and Extras security teams work together.  There probably won't be
>  much overlap, but often the analysis is the most important part of dealing
>  with security issues.
>   
So I can see Legacy and Extras folks working together in terms of
discussion and best practices, but I wanted to avoid Extras maintainers
'dumping' their packages on the Legacy project to maintain the security
updates.  Legacy exists because Red Hat doesn't want to pay their
developers to continue maintaining security updates for outdated
releases.  This is very fair.  Legacy is taking the place of those
maintainers.  Extras has no such problem in this aspect, an Extras
maintainer should be in for a pinch, in for a mile.  In fact, if
anything I'd like to see some of the Extras maintainers putting in some
work on testing/building/whatevering packages within the Legacy space.
This will be much easier to do once Legacy switches over to an Extras
like build system (soon) including a copy of the Fedora CVS contents.
These things are indeed up for discussion.

-- 
Jesse Keating
Release Engineer: Fedora