Package installation for Linux distributions has traditionally separated
libraries and application binaries into different packages, so that only one
version of a library would be installed and it would be shared by
applications that use it. Other operating systems
(e.g. Windows, MacOS X) often bundle a particular version of a library with
each application, which can lead to many copies and versions of the same
library co-existing on the system. While each model has its advocates, the
Linux method is seen by many as superior because a security fix in a
particular commonly-used library doesn't require updating multiple
applications—not to mention the space savings. But, it would seem
that both Mozilla and Google may be causing distributions to switch to
library-bundling mode in order to support the Firefox and Chromium web browsers.
One of the problems that distributions have run into when packaging
Chromium—the free software version of Google's Chrome
browser—is that it includes code for multiple, forked libraries. As
Fedora engineering manager Tom "spot" Callaway put it: "Google is
forking existing FOSS code bits for Chromium like a rabbit makes babies:
frequently, and usually, without much thought." For distributions
like Fedora, with a "No
Bundled Libraries" policy, that makes it very difficult to include
Chromium. But it's not just Chromium.
Mozilla is moving to a different
release model, which may necessitate distribution changes. The idea is
to include feature upgrades as part of minor releases—many of which
are done to fix security flaws—which would come out every 4-6 weeks
or so. Major releases would be done at roughly six-month intervals and older
major releases would stop being supported soon after a subsequent release. Though
the plan is
controversial—particularly merging security and features into the
minor releases—it may work well for Mozilla, and the bulk of
Mozilla's users who are on Windows.
Linux distributions often extend support well beyond six-months or a year,
Mozilla is still supporting a particular release, that's easy to do, but
once Mozilla stops that support, it becomes more difficult. Distributions
have typically backported security fixes from newer Firefox versions into
the versions that they shipped, but as Mozilla moves to a shorter support
window that gets harder to do. Backporting may also run afoul of the Mozilla
trademark guidelines—something that led Debian to create "Iceweasel".
The alternative, updating
Firefox to the most recent version, has its own set of problems.
A new version of Mozilla is likely to use updated libraries, different from
those that the other packages in the distribution use. Depending on the
library change, it may be fairly straightforward to use it for those other
applications, but there is a testing burden. Multiple changed libraries
have a ripple effect as well. Then there is the problem of xulrunner.
Xulrunner is meant to isolate applications that want to embed
Mozilla components (e.g. the Gecko renderer) from changes in the Mozilla
platform. But xulrunner hasn't really committed to a stable API,
so updates to xulrunner can result in a cascade of other updates. There
are many different packages (e.g. Miro, epiphany, liferea, yelp, etc.) that
use xulrunner, so changes to that package may require updates to those
dependencies, which may require other updated libraries, and so on.
The Windows/Mac solution has the advantage that updates to Firefox do not
require any coordination with other applications, but it has its set of
downsides as well. Each application needs some way to alert users that
there are important security fixes available and have some mechanism for
users to update the application. Rather than a central repository that can
be checked for any pending security issues, users have to run each of their
installed applications to update their system. Furthermore, a flaw in a
widely used library may require updating tens or hundreds of applications,
whereas, in the Linux model, just upgrading the one library may be sufficient.
It would appear that Ubuntu is preparing
to move to the bundled library approach for Firefox in its upcoming 10.04
(Lucid Lynx) release. That is a "long-term support" (LTS) release that
Ubuntu commits to supporting for three years on the desktop. One can
imagine that it will be rather difficult to support Firefox 3.6 in 2013, so
the move makes sense from that perspective. But there are some other
implications of that change.
For one thing, the spec mentions the need to "eliminate
embedders" because they could make it difficult to update Firefox:
"non-trivial gecko embedders must be eliminated in stable ubuntu
releases; this needs to happen by moving them to an existing webkit
variant; if no webkit port exists, porting them to next xulrunner branch
needs to be done." Further action items make it clear that finding
WebKit alternatives for Gecko-embedders is the priority, with removal from
Ubuntu (presumably to "universe") being the likely outcome for most of the
In addition, Ubuntu plans to use the libraries that are bundled with
Firefox, rather than those that the rest of the system uses, at least
partially because of
user experience issues: "enabling system libs is not officially
supported upstream and supporting this caused notable work in the past
while sometimes leading to a suboptimal user experience due to version
variants in the ubuntu released compared to the optimize version shipped in
the firefox upstream tarballs." While it may be more in keeping
with Mozilla's wishes, it certainly violates a basic principle of Linux
distributions. It doesn't necessarily seem too dangerous for one
package, but it is something of a slippery slope.
The release model for Chromium is even more constricting as each new
version is meant to supplant the previous version. As Callaway described,
it contains various modified versions of libraries, which makes it
difficult for distributions to officially package in any way other than
with bundled libraries. If that happens in Ubuntu for example, that would
double the number of applications shipped with bundled libraries. Going
from one to two may seem like a fairly small thing, but will other
heading down that path?
The Fedora policy linked above is worth reading for some good reasons not
to bundle libraries, but there are some interesting possibilities in a
system where that was the norm. Sandboxing applications for security
purposes would be much more easily done if all the code lives in one place
and could be put into some kind of restrictive container or jail.
Supporting multiple different versions of an application also becomes easier.
It is fundamentally different from the way Linux distributions have
generally operated, but some of that is historical. While bandwidth may
not be free, it is, in general, dropping in price fairly quickly. Disk
space is cheap, and getting cheaper; maybe there is room to try a different
approach. The distribution could still serve as a central repository for
packages and, perhaps more importantly, as a clearinghouse for security
advisories on those packages.
Taking it one step further and sandboxing those applications, so that any damage
caused by an exploit is limited, might be a very interesting experiment.
The free software world is an excellent candidate for that kind of
trial, in fact it is hard to imagine it being done any other way; the
proprietary operating systems don't have as a free a hand to repackage the
applications that they run. It seems likely that the negatives will
outweigh the advantages, but we won't really know until someone gives it a try.
to post comments)