Firefox in Breezy (1.0.8), and security support
iwj at ubuntu.com
Wed Jun 7 15:54:43 BST 2006
I have been investigating the situation with firefox 1.0.8 in Breezy
given the presence of known security problems in 188.8.131.52 in Dapper
(for which we are planning to deploy 184.108.40.206 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 220.127.116.11 and 18.104.22.168 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
2. The code has changed very considerably between 1.0.8 and 22.214.171.124 in
many of the areas affected by the changes.
The effect of these two factors is to make it impractical to
selectively backport the 126.96.36.199->188.8.131.52 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 184.108.40.206 release
notes, with the assitance of the 220.127.116.11->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
There are some other already-known facts that are relevant here:
3. We know that the 18.104.22.168->22.214.171.124 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
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 126.96.36.199 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 188.8.131.52. We know
that this can be done (early Dapper 184.108.40.206's were obviously
backports; I haven't checked backports.org but I don't see any
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
Thanks for your attention.
More information about the ubuntu-devel