Re: Firefox and Sarge
On Wed, Aug 25, 2004 at 11:35:10AM +1000, Andrew Pollock wrote:
> On Tue, Aug 24, 2004 at 11:02:20AM -0700, Matt Zimmerman wrote:
> > We cannot release software that we are unable to support.
>
> And not releasing an extremely popular package isn't really ideal either.
>
> My understanding of the stable update policy is if a package is really too
> hard to backport, it can be argued that a newer version is okay for a
> security update. I believe this happened with openssh once upon a time, and
> I believe it was also a semi-disaster.
That was actually a different situation: openssh upstream essentially forced
us (and other vendors) to upgrade to a newer ssh, and endure all of the
problems that this caused. It had nothing to do with whether or not a
backport was feasible.
When the details were revealed, it turned out that of the two
vulnerabilities, one did not even affect Debian, and the other was in fact
trivial to patch. However, due to the circumstances, we had to endure a
large, complex security update which severely broke many Debian systems and
required several iterations in order to achieve some measure of stability.
Now, consider that other packages generally only interface with ssh through
a simple command-line API, if at all, while Mozilla is a build-dependency of
several other packages, and provides a complex and frequently-changing
library API. Mozilla furthermore tends to upgrade poorly from older
versions such as the one in woody. This makes it quite a poor candidate for
introducing a new upstream version into stable.
On the other hand, Mozilla has changed a great deal since woody, and it's
often unclear whether a bug even applies to this ancient code, much less how
to fix it, without a great deal of research. This makes it also a poor
candidate for backporting.
The conclusion is that Debian cannot, on its own, effectively support
ancient releases of huge and complex software packages by either means.
> But on a case by case basis, maybe a bit more this needs to happen, rather
> than being bloody-minded about backporting security fixes where it's just
> too much work.
The assumption that backporting is more work is largely erroneous, when you
consider both development and QA. The idea of backporting is to fix a bug
while reducing the chance of regressions by introducing many other changes.
By limiting the changes to specific areas of the code, the chance of
regressions is reduced, and QA is simplified. In the common case, fixing a
vulnerability by backporting is on the whole less work than attempting to
provide a new upstream release with the same level of confidence.
--
- mdz
Reply to: