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
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
