Security Response Team / EOL

[Michael J Knox]

Sounds great!

My hand is raised nice and high to help with both aspects (if needed).

Michael

Thorsten Leemhuis wrote:
> Hi all!
> 
> The proposals for the Security SIG (from now on called "Fedora Extras
> Security Response Team") and the EOL Plans for older Fedora
> Extras releases linger around for some time already -- but ATM they are
> stuck a bit. Partly that's maybe my and FESCo's fault, but both topics
> are controversial (even within FESCo there are different opinions how to
> actually solve all the issues) and that's probably the biggest problem.
> 
> Anyway, we need to get the ball running somehow. That's what I'm trying
> to achieve with this mail. Why both topics together? Well, one part of
> the EOL planing IMHO depends on a bit on parts of the Security Response
> Team.
> 
> So, this is my proposal ("my" actually is the wrong word -- it are other
> proposals put together and one mail and slightly
> enhanced/modified/clarified). First the Security Response Team.
> Interested in this topic and working on it in the past weeks are at
> least: Hans de Goede, Jason L Tibbitts III , Dennis Gilmore, Jochen
> Schmitt, Ville Skyttä, and Josh Bressers. 
> 
> 
> === Fedora Extras Security Response Team
> 
> Josh Bressers seems to be the one ATM who wants to drive this forward.
> He volunteered to "to do the initial painful startup work". I suggest he
> should act as leader of the Security SIG in the beginning
> 
> The planed Security Response Team has this purposes for now:
> 
> - Monitor various security information sources for potential security
>   problems (old and new ones)
> - When an issue is discovered: file appropriate bugs, alerting the
>   maintainer of the need to patch their package.
> - Maintain list of fixed and unfixed security issues in a public CVS
>   repository (similar how it is done for core)
> - Create and post announcements for fixed packages to proper mailing
> lists
> - Encourage and foster public discussion of various security issues and
>   procedures via the fedora-security mailing list.
> 
> Those are the most important things for now. There are some things that
> probably should be implemented and discussed after the Security Response
> Team is in place:
> 
> - Handling embargoed issues / Bugs marked as private
> - A method of high-priority submission to the build system
> - The Extras project as a whole needs a way for a maintainer to
> designate
>   that they have dropped maintenance of a particular branch. We need
> this
>   to know if we need to wait for a maintainer.
> 
> Besides this most important task there is one more: Normally the
> maintainers are 100% responsible for the security updates for their own
> packages -- but
> 
> - *if the maintainer doesn't respond in x days after a bug was filed*
> ("x" still needs to be defined -- the wiki has a good scheme that might
> be the right one)
> - if the maintainer is on holiday (we have a list in the wiki)
> - if the package/the specific package branch is orphaned
> or
> - if the maintainer needs help
> 
> The Security Response Team will lend assistance as needed.
> 
> (Note: There was a small discussion that the latter part of this
> proposal should be handled by a own SIG/Team/Task Force -- this idea was
> dropped for now, but can be put back on the table later if it should be
> needed)
> 
> 
> === EOL.
> 
> When a Fedora Core release reaches Maintenance state (such as Fedora
> Core 3 reached when Fedora Core 5 Test 2 was released), the
> corresponding release of Fedora Extras will also enter a Maintenance
> state. In this state maintainers will be allowed to issue updates to
> existing packages, but Maintainers are strongly urged to only issue
> severe bugfix or security fixes. New software versions should be avoided
> except when necessary for resolving issues with the the current version.
> 
> Branches for new packages in CVS are not created for Distributions
> that are in Maintenance state. FESCo can approve exceptions of this rule
> if there are good reasons for it. The official package maintainers are
> urged to fix their packages also for Distributions that are in
> Maintenance state. They should work hand in hand with the "Security
> Response Team" in case they don't have access to older
> distros anymore to test their updates. 
> 
> When the Fedora Project drops support for a Fedora Core release the
> corresponding Fedora Extras is also dropped -- read this as
> "End-of-life, no new updates,support for that EOL distro will be removed
> from the Extras buildsys". 
> 
> The EOL Policy depends on the creation and a working Security Response
> Team and especially the part of it that "will lend assistance as needed"
> if the maintainer is unable to fix the package -- if that group does not
> start working properly until June 15 2006 we'll send out a EOL for
> Fedora Extras 3 -- means: "Packagers can still update things in cvs and
> build updates for now, but the official state of Fedora Extras 3 is
> 'unsupported and End of Life'". In that case we'll try to improve for
> FE4 and later.
> 
> ====
> 
> Comments please. FESCo will probably vote on this proposal (or an
> enhanced version if the discussion on this list has productive results)
> of it in the next meeting. Of course everybody can bring in other
> proposals and we'll pick the one that seems to be the best.
> 
> CU
> thl
>