The coming WebKitGTK+ 2.4 apocalypse

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

It is well understood that old and unmaintained software tends to be a breeding ground for security problems. These problems are never welcome, but they are particularly worrying when the software in question is a net-facing tool like a web browser. Standalone browsers are (hopefully) reasonably well maintained, but those are not the only web browsers out there; they can also be embedded into applications. The effort to do away with one unmaintained embedded browser is finally approaching its conclusion, but the change appears to have caught some projects unaware.

In early 2016, Michael Catanzaro sounded the alarm about security issues with the widely used WebKitGTK+ browser engine. At the time, security issues were turning up in WebKitGTK+ with great regularity, but nobody was calling them out as such; as a result, they were not getting CVE numbers and distributors were not bothering to ship updates. That created a situation where Linux desktop systems were routinely running software that was known to have security issues that, in many cases, could be exploited via a hostile web page or HTML email attachment.

Eighteen months later, Linux users can count themselves as the beneficiaries of a great deal of focused work on the part of Catanzaro and his colleagues. WebKit vulnerabilities and, in particular, vulnerabilities that show up in WebKitGTK+, are now regularly fixed by most (but not all) mainstream Linux distributions. Even the abandoned QtWebKit engine has picked up a new maintainer and is now "only" a year and a half behind the current WebKit release which, Catanzaro notes, "is an awful lot better than being four years behind". Progress is being made.

Progress in one part of the software ecosystem has a way of highlighting the relative lack of progress elsewhere, though. As Catanzaro explains in detail in his 2016 post, there are multiple versions of the WebKitGTK+ API, one of which ("WebKit1") was last supported in WebKitGTK+ 2.4, which was released in early 2014 and has not seen any security fixes for a long time. To stay current, applications need to move forward to the current WebKitGTK+ API, a process which can involve significant amounts of pain depending on how involved the application is in the rendering process. For applications that just need the engine to render some HTML, the API change is evidently not that hard to deal with. Or, at least, that is the case if moving to a current WebKitGTK+ release doesn't present other sorts of API issues. That is where the rub turns out to be.

GNOME is based on the GTK+ toolkit; as one would expect from the name, WebKitGTK+ also uses GTK+. But WebKitGTK+ versions after 2.4 only use GTK+ version 3.x, having left support for GTK+ 2 behind. GTK+ 3.0 was released in early 2011, meaning that application developers have had over six years to make the change. But, should there happen to be any laggard applications out there that have not moved forward to current GTK+, they will also be unable to move to anything resembling a current WebKitGTK+ browser engine. This could be a problem, as distributions are starting to simply remove their WebKitGTK+ 2.4 packages, breaking any applications that depend on it in the process.

Which applications might those be? On a Fedora 26 system, a query turns up these packages:

The Banshee music player. The 2.6.2 release shipped by Fedora came out in 2014; the project's web page mentions a 2.9 development release that also came out in 2014.

The claws-mail email client and, in particular, the "fancy" plugin used to render HTML mail. Claws seems to have a reasonably active development community, but it would appear to be more focused on producing minor releases with obnoxious changes to default behavioral settings than moving to GTK+ 3. A request for GTK+ 3 support filed in 2011 drew the response: " Good luck to whoever tries to work on that task ". More recently, developers have started to work on the problem more seriously, but it's not clear when the work will be done.

". More recently, developers have started to work on the problem more seriously, but it's not clear when the work will be done. gmusicbrowser, another music player. It last released in 2015; the repository shows no commits for over a year.

The GnuCash financial application. GnuCash, too, seems to have an active (if small) development community. The 2015 bug report also shows a slow start to the problem, but GnuCash is nearing a 2.8 release that should include the required updates. The project is looking at moving away from WebKitGTK+ altogether, since it's overkill for the task of drawing a few charts.

The kazehakase web browser. The latest release shown on the web site is from 2009.

The Lekhonee WordPress publishing tool, which does not appear to have a current web page anywhere.

mono-tools. The last commit was a license change in 2016.

SparkleShare, a file-synchronization application, last released in 2015.

Techne, a simulation package last released in 2011.

Tech Talk PSE, billed as " superior technical demonstration software ". One commit in 2015, otherwise nothing since 2012.

A quick check on an openSUSE Tumbleweed system turns up others, including the Midori browser (last release in 2015).

One suspects that many of the above packages could simply vanish with few users even noticing. But some of them, including claws-mail and GnuCash, have significant user communities. They have, at this point, been fairly publicly caught out and revealed as failing to keep up with changes in the environment in which they run. The results go beyond shipping an application dependent on an outmoded toolkit; an email client should not be feeding arbitrary attachments to a browser engine with known security problems, for example.

Users of some of the faster-moving distributions are already seeing the effects of this move. Arch has already dropped WebKitGTK+ 2.4, and Fedora will do the same in its next release. Expect some scrambling as the developers of affected applications (those which still have developers, obviously) scramble to do forward-porting work that probably should have been completed several years ago and completely unmaintained applications just disappear. Development communities can be just like the rest of us: happy to procrastinate until the deadline looms. Arguably, distributors should make a point of imposing such deadlines more often.

