When following the distributions' security updates on a daily basis, as we
do at LWN, certain days are more work than others. Two weeks ago we had a
rather full update with no
less than 28 packages updated for Fedora (most of those for both F7 and
F8), along with a handful of updates from other distributions. It turns
out that the majority of the Fedora updates had a single cause: a set
of serious vulnerabilities in Mozilla Firefox.
How does a single update to an application ripple so far that more than a
dozen packages have to be rebuilt? One would think there would be shared
libraries that would get updated, with applications picking up those
changes the next time they are run. That is, in theory, how things are
supposed to work, but in this case, the underlying libraries have no fixed application
binary interface (ABI). So, changes to those libraries require any
applications that use them to be rebuilt and retested.
Gecko is the rendering engine used by Mozilla in their products to display
HTML. Various other packages have started using it as well because of its
speed and standards compliance. Because Mozilla sometimes breaks
the ABI between releases, even minor releases, distributions may be stuck
rebuilding those applications when a new version of the library is
released. Normally, that only happens when packaging a new version of the
distribution—or when serious security flaws are found.
Mozilla's solution for this problem is XULRunner which
will provide a stable ABI for applications. As XULRunner and its companion
libxul become more widely available, the applications that
currently link to the Gecko libraries will presumably switch to avoid these
kinds of problems in the future. It is highly unlikely that we have seen
the last security problem in the Gecko engine, so reducing the cascade that
results from finding one would be welcome.
Because of problems with the ABI changing in the past, Fedora chooses to
make the applications' library version number exactly track the Mozilla release number.
Some other distributions do not do that, so unless the ABI does change, they do
not need to update each package that uses the libraries. This has some
advantages, but could lead to broken applications if an ABI change goes
We have also seen similar cascades of updates, most notably from the xpdf PDF viewer. Unlike
Gecko, there is no library for xpdf, leading multiple applications to
include its source into their own. When a flaw is found, several different
applications (cups, gpdf, etc.) across all distributions need to
be updated immediately, leading to a similar effect as was seen with the
Gecko vulnerabilities. Hopefully, over time, the development of the poppler library will mitigate
this problem somewhat.
There are lots of good reasons to separate code into components where
possible, but security is an important one. Creating and maintaining an ABI
is sometimes difficult, but generally worth the trouble. Imagine the chaos
that could result from a security vulnerability requiring an ABI change in
to post comments)