Firefox in Breezy (1.0.8), and security support

[Ian Jackson]

I have been investigating the situation with firefox 1.0.8 in Breezy
given the presence of known security problems in 1.5.0.3 in Dapper
(for which we are planning to deploy 1.5.0.4 from upstream just as
soon as dapper-security is open).

The situation isn't very good, and none of our options look
particularly good.  I thought I should report on what I have
discovered so that we discuss and decide what to do.


As I suspected,

1. The diff between 1.5.0.3 and 1.5.0.4 is very large and contains
   many changes that could not be described as security or stability
   fixes.  It includes (just as an example) dozens of changes to files
   which are not compiled or used in any sane configuration of firefox
   1.5.0.3.

2. The code has changed very considerably between 1.0.8 and 1.5.0.3 in
   many of the areas affected by the changes.

The effect of these two factors is to make it impractical to
selectively backport the 1.5.0.3->1.5.0.4 diff to our firefox.

The obvious alternative approach would be to try to identify in the
1.0.8 source the problems described by the CVEs and 1.5.0.4 release
notes, with the assitance of the 1.5.0.3->4 diff, and to craft new
fixes for 1.0.8 and release them in Breezy.  This should be possible
in principle but obviously it's a lot of effort and for reasons I'll
go on to explain I don't think it's sufficient or necessarily the
right answer.


There are some other already-known facts that are relevant here:

3. We know that the 1.5.0.2->1.5.0.3 diff contained what look like
   fixes to security problems not listed in the published release
   notes nor in the CVE list provided to me by Martin.

4. Our firefox in Breezy contains a total of about 60klines of diff
   even from upstream 1.0.8, including what amount to `backports' of
   substantial pieces of i18n and rendering code (much of it present
   only in Ubuntu and not in Debian).  That is, early versions of some
   changes were taken from the Mozilla Bugzilla and applied to our
   browser.  During the 1.5 merge for Dapper, I found that in general
   the relevant functionality was included in 1.5, but in each case
   1.5 had a newer implementation.

Together with the desupport upstream of 1.0.x, this means that
Breezy's Firefox has no security support from upstream and contains a
significant amount of code which has never been given security
support, nor released, by anyone else.

For upstream-supported versions this isn't true; the Mozilla
organisation is the best channel for reporting bugs in Mozilla
products and there is evidence that although their release and
documentation processes are poor, they do actually fix bugs.
Furthermore, as a highly visible and central player, they have a
reputation to maintain on this point.

So, the code our users are running is substantially different from any
code that has anything like a well-supported a mechanism for capturing
and dealing with reports of security problems.  Indeed, if someone
discovers a vulnerability in Firefox 1.0.8 I have no confidence that
Mozilla would deal with it appropriately or that we would hear about
it.


So I think we have a problem and ought to be creative in our thinking
about this problem.  Brainstorming, without ruling out any of the
options, I can think of at least the following options for Ubuntu:
 - End support for Breezy.
 - End security support for web browsing in Breezy with
       some appropriately scary announcement.
 - Attempt to address only known vulnerabilities (inventing new fixes
       as described above) and hope that this is sufficient.
 - Provide a version of firefox 1.5.0.4 in breezy-security.
 - Ignore the problem completely, do nothing, and hope no-one notices.
 - Try to form some kind of consortium with other distros to do
       security support for some or all obsolete products
       (perhaps just firefox 1.0.8, perhaps others too).
 - Persuade Mozilla to change their mind about ending security
       support for 1.0.8.
Most of these are unpalatable, very difficult, or both.

I think by far the most attractive is to backport 1.5.0.4.  We know
that this can be done (early Dapper 1.5.0.4's were obviously
backports; I haven't checked backports.org but I don't see any
fundamental problems).

If we are careful with review of the _packaging_ arrangements as
opposed to the _code_ arrangements, we should be able to avoid too
much damage, and careful testing will help too.  So I think we
should be able to provide a reasonable user experience.

This model could also be used well into the future, especially
considering the LTS requirement for Dapper.  If we know in advance
that this is what our plan is, we can prepare, carefully test, and
then finally deploy a future Firefox 2.0 into dapper-updates and
dapper-security, before we are forced into the position of having to
delay while we think of a way to deal with a pressing security
problem.


Thanks for your attention.

Ian.