Re: Updating scanners and filters in Debian stable (3.1)
Martin Schulze <joey@infodrom.org> wrote:
> Josselin Mouette wrote:
>> IMHO, this is insane. It means we have absolutely zero support for
>> security updates on e.g. mozilla or OOo. This is a great disservice to
>> our users.
>
> Maybe these packages are not suited for stable if it's impossible to
> support them security-wise?
Serving our users is more important than slavish adherance to leaving
stable almost untouched. Nobody is usefully served by us failing to ship
Mozilla or Openoffice. However, the status-quo also seems less than
ideal.
Current situation: People install Mozilla. It's insecure. However,
functional regressions are never introduced during the life of stable.
In the worst case, admins can remove Mozilla.
Solution a: Newer versions of Mozilla are introduced. Functional
regressions are possible. However, admins have the choice of setting
Mozilla's status to hold. In the worst case, this solution can be made
equivilent to the current situation.
Solution b: Security fixes are backported to Mozilla. The size of the
codebase may make this impractical, and functional regressions are still
possible. However, admins have the choice of setting Mozilla's status to
hold. In the worst case, this solution can be made equivilent to the
current situation.
Solution c: We don't ship Mozilla. This is always equivilent to the
worst case of the current situation.
A or B sound preferable to either the current situation or C. The
maintainers have, in the past, suggested that B is very difficult or
impossible. If we can't find a way to deal with that, solution A still
sounds better than the alternatives.
Perhaps the real problem here is that we seem to be unwilling to have a
public policy of some packages being more important than others. Letting
Mozilla get updated in stable might result in people wanting other
programs to be updated. This is silly, for two reasons:
1) There are actually a fairly small number of security sensitive
programs that are so large that backporting fixes is very difficult.
Anything that didn't fall into this catagory wouldn't be appropriate.
2) Our users care much, much, MUCH more about Mozilla than they do about
the GTK 1.2 version of Yet Another Clock Applet 3. Packages can be
looked at on a case by case basis and the importance of fixing them
judged accordingly.
We should be more willing to accept that there is some code that is both
more important and more difficult to fix than the majority of what we
ship. There are good arguments to hold that code to a different standard
to other packages.
--
Matthew Garrett | mjg59-chiark.mail.debian.devel@srcf.ucam.org
Reply to: