Endgame for WebKit Woes

In my original blog post On WebKit Security Updates, I identified three separate problems affecting WebKit users on Linux:

  • Distributions were not providing updates for WebKitGTK+. This was the main focus of that post.
  • Distributions were shipping a insecure compatibility package for old, unmaintained WebKitGTK+ 2.4 (“WebKit1”).
  • Distributions were shipping QtWebKit, which was also unmaintained and insecure.

Let’s review these problems one at a time.

Distributions Are Updating WebKitGTK+

Nowadays, most major community distributions are providing regular WebKitGTK+ updates, so this is no longer a problem for the vast majority of Linux users. If you’re using a supported version of Ubuntu (except Ubuntu 14.04), Fedora, or most other mainstream distributions, then you are good to go.

My main concern here is still Debian, but there are reasons to be optimistic. It’s too soon to say what Debian’s policy will be going forward, but I am encouraged that it broke freeze just before the Stretch release to update from WebKitGTK+ 2.14 to 2.16.3. Debian is slow and conservative and so has not yet updated to 2.16.6, which is sad because 2.16.3 is affected by a bug that causes crashes on a huge number of websites, but my understanding is it is likely to be updated in the near future. I’m not sure if Debian will update to 2.18 or not. We’ll have to wait and see.

openSUSE is another holdout. The latest stable version of openSUSE Leap, 42.3, is currently shipping WebKitGTK+ 2.12.5. That is disappointing.

Most other major distributions seem to be current.

Distributions Are Removing WebKitGTK+ 2.4

WebKitGTK+ 2.4 (often informally referred to as “WebKit1”) was the next problem. Tons of desktop applications depended on this old, insecure version of WebKitGTK+, and due to large API changes, upgrading applications was not going to be easy. But this transition is going much smoother and much faster than I expected. Several distributions, including Debian, Fedora, and Arch, have recently removed their compatibility packages. There will be no WebKitGTK+ 2.4 in Debian 10 (Buster) or Fedora 27 (scheduled for release this October). Most noteworthy applications have either ported to modern WebKitGTK+, or have configure flags to disable use of WebKitGTK+. In some cases, such as GnuCash in Fedora, WebKitGTK+ 2.4 is being bundled as part of the application build process. But more often, applications that have not yet ported simply no longer work or have been removed from these distributions.

Soon, users will no longer need to worry that a huge amount of WebKitGTK+ applications are not receiving security updates. That leaves one more problem….

QtWebKit is Back

Upstream QtWebKit has not been receiving security updates for the past four years or thereabouts, since it was abandoned by the Qt project. That is still the status quo for most distributions, but Arch and Fedora have recently switched to Konstantin Tokarev’s fork of QtWebKit, which is based on WebKitGTK+ 2.12. (Thank you Konstantin!) If you are using any supported version of Fedora, you should already have been switched to this fork. I am hopeful that the fork will be rebased on WebKitGTK+ 2.16 or 2.18 in the near future, to bring it current on security updates, but in the meantime, being a year and a half behind is an awful lot better than being four years behind. Now that Arch and Fedora have led the way, other distributions should find little trouble in making the switch to Konstantin’s QtWebKit. It would be a disservice to users to continue shipping the upstream version.

So That’s Cool

Things are better. Some distributions, notably Arch and Fedora, have resolved all of the above problems (or will in the very near future). Yay!

8 Replies to “Endgame for WebKit Woes”

  1. As a user of both Gnome and many Qt/KDE applications, what I really wish for is a merger of QtWebKit and WebKit-GTK at some point. Not merging toolkits, obviously, but merging release management. With the GTK and Qt versions being developed both on top of WebKitGTK’s build CMake system, the release for both should be the same tarball just using the -DPORT=Qt compiler option once Konstantin completes the code base update, right?

    The Qt world really lacks a properly maintained web renderer. Qt Company is unable or unwilling to make monthly bugfix releases of their Chromium-derived port decoupled from main Qt releases (Fedora 24 ships a git snapshot of Qt WebEngine 5.6.3 because the last update for this “LTS” version was in October). The closest thing to a properly maintained Qt web renderer is actually KHTML (released as part of KDE Frameworks5) but obviously that one cannot compete with Apple’s or Google’s resources when it comes to implement web standards.

    Any realistic chance for my wish to come true?

    1. The Qt port can’t go upstream because it’s being developed by one (awesome) guy and not a team of full-time developers. So no real chance for your wish to come true. The QtWebKit code just does not exist in the upstream WebKit repository, and I don’t think we’d want to switch to releasing tarballs from a downstream codebase.

      But fear not: QtWebKit is actually now based on the upstream WebKitGTK+ stable branches. So most of the work of backporting fixes will be shared between the two ports. That’s the hardest part of release management.

      1. It’s not yet in upstream WebKit SVN but I seem to recall emails by Konstantin to WebKit or Qt mailing lists that this is eventually the goal.

        My wish/question wasn’t referring to any time before that.

        1. He knows that can’t happen. He’s trying to get it into the upstream QtWebKit repo instead.

          1. Because all the old developers quit and went to work on QtWebEngine instead. Konstantin is the only person working on QtWebKit now as far as I know. Small ports are not accepted upstream as they are a burden on WebKit development. It would need a team of paid developers to be reconsidered. Even then, there is going to be some hesitation to bring back a bunch of Qt code, or code that’s only used by Qt, that we’ve previously removed.

          2. >He’s trying to get it into the upstream QtWebKit repo instead.

            It’s already there, actually

  2. It is a shame that OpenSUSE lags behind so much. For Debian Stretch there is at least the backports repository which provides a current webkit2gtk (2.16.6-1~bpo9+1).

    Additionally a look at the situation in the BSD world:
    – FreeBSD ports have webkit2-gtk3-2.16.6 but do also provide the old version 2.4.11
    – Similar the situation in OpenBSD: ports have webkitgtk4-2.16.6 but 2.4.11 as well
    – NetBSD’s pkgsrc has only webkit-gtk-2.12.4nb6 (and 2.4.11).
    So, with FreeBSD and OpenBSD everything seems to be all right about shipping a current WebKitGTK+ version. Sadly NetBSD doesn’t follow their example. But all BSD’s do still offer the ancient version 2.4.11

Comments are closed.