Hi,
I should probably send this to debian-devel, but I wanted to share it
here first to get some feedback from the team.
the TL;DR version of this e-mail is that sooner or later we won't be
able to keep updating WebKitGTK on some of Debian's official
architectures. This is imminent 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 going to start changing soon. Two years ago
WebKitGTK started to use Skia for rendering because it performs much
better than the old Cairo backend[2], and earlier this year Cairo
support was removed[3] in the development branch.
But Skia only supports little-endian platforms, so the upcoming 2.54
branch of WebKitGTK won't build on big-endian platforms, which in the
case of Debian means s390x and many of the unofficial ones. This is
already happening in the packages in experimental, and is about to
happen in unstable.
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 many 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). All reverse
dependencies would need to disable WebKitGTK support 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, I think the best option is (2).
And I think this is all. Feedback is welcome!
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
