Hi,
the TL;DR version of this e-mail is that at some point in the future
we won't be able to keep updating WebKitGTK on some of Debian's
official architectures. This is happening right now in the case of
s390x, but others will follow later.
Keep reading for the long version of this story.
As you all probably know, the WebKitGTK web engine (src:webkit2gtk in
Debian) is a port of Apple's WebKit, one of the three major open
source web engines, and unlike Mozilla's Gecko or Google's Blink, it
is designed to be a standalone component ready to be embedded by any
app that wants to render web content.
As such, there is a multitude of packages using WebKitGTK in Debian,
including web browsers (epiphany, luakit, surf), e-mail clients
(evolution, balsa) and other apps such as yelp, gnucash, liferea,
gnome-boxes, gnome-builder, etc.
WebKit is very actively developed (with ~400 commits per week).
WebKitGTK makes new point releases every few weeks, and a new major
release every 6 months, coinciding with the GNOME release cycle.
Like any other web engine, WebKit is affected by a constant stream of
security vulnerabilities. Due to the complexity of the project, it's
not feasible to cherry-pick the security fixes to older versions of
the package[1], so we backport the most recent stable release instead.
This has been working fine for many years with almost no issues, and
WebKitGTK has a dependency policy (agreed with Apple) to ensure that
it remains buildable with the compilers and libraries available in the
stable versions of Debian and Ubuntu. This means that users of Debian
stable (and, to some extent, oldstable) simply get the most recent
version of WebKitGTK (via debian-security and Debian point releases)
and things just work.
So far so good, and to this day WebKitGTK has remained buildable on
all official Debian architectures.
Things are however starting to change. Two years ago WebKitGTK started
to use Skia for rendering because it performs much better than the old
Cairo backend[2]. Earlier this year Cairo support was removed[3] and
that change has finally reached the new stable release.
But Skia only supports little-endian platforms, so the latest release
of WebKitGTK (2.54) doesn't build on big-endian platforms. In the case
of Debian this means s390x and many of the unofficial ones. This is
already happening in the packages in experimental, and is about to
happen in unstable (see #1148038).
I don't think this is a big problem for Debian as I don't expect
anyone to be seriously using WebKit on an s390x box, but it's an
indication of other changes to come in the future.
Notably, Apple has been adding Swift code to WebKit for a few years
already. While this was initially limited to the Apple-specific parts
of the project, Swift is increasingly going to be used in the
cross-platform code, and at some point in the future a working Swift
toolchain will be a requirement to build WebKitGTK. We don't know when
that is going to happen, certainly not during 2026 because of the
6-month release cycle I mentioned. It could be during 2027, it could
be later.
This will have its own set of challenges (most notably ABI stability
issues) that will have to be dealt with. I want to stress that Apple's
WebKit and Swift teams have been supportive and they are interested in
having successful Linux ports of WebKit and in listening to our
feedback, concerns and doubts.
Having said that, Swift is currently only supported on amd64 and arm64
(at least in Debian) and while other architectures may or may not
appear in the future, we're definitely going to have to stop building
WebKitGTK on some of the official Debian architectures.
This leaves us in a situation where a library that is used by many
desktop packages is going to disappear from several of the official
architectures sooner or later.
From here I think we have three different options:
(1) Stop upgrading WebKitGTK and stick to the latest version that
builds everywhere. CVEs would start to pile up and WebKitGTK would
basically become dead downstream.
(2) Stop building WebKitGTK on arches where it's not feasible
(i.e. soon everything except amd64 and arm64, maybe more if Swift
arrives to others). All reverse dependencies would need to disable
WebKitGTK on the unsupported architectures (where possible).
(3) Add a new src:webkitgtk-legacy package for unsupported
architectures, with the latest version that works everywhere, and
keep src:webkit2gtk up-to-date on the supported ones. For amd64 /
arm64 users nothing would change, and other users would have to
use a dead version of WebKitGTK with no security updates.
I think that the worst one is (1), the easiest one is (2) and the best
one is probably (3).
However, even case (3) won't work forever since it is to be expected
that at some point reverse dependencies like epiphany or evolution
will start having problems supporting old versions of WebKitGTK.
For the big-endian targets, unless someone manages to make Skia work
on those machines the option is (2) (again, see #1148038).
In the case of QtWebEngine and other Chromium-based packages: Chromium
stopped using WebKit more than 10 years ago and has a completely
independent codebase. Therefore it's not affected by any of this.
Regards,
Berto
[1]
https://www.debian.org/releases/trixie/release-notes/issues.en.html#security-status-of-web-browsers-and-their-rendering-engines
[2] https://webkitgtk.org/2024/10/04/webkitgtk-2.46.html
[3] https://bugs.webkit.org/show_bug.cgi?id=306269
