Catanzaro: An Update on WebKit Security Updates [LWN.net]

Michael Catanzaro looks at how distributors have improved (or not) their security support for the WebKit browser engine in the last year. "So results are clearly mixed. Some distros are clearly doing well, and others are struggling, and Debian is Debian. Still, the situation on the whole seems to be much better than it was one year ago. Most importantly, Ubuntu’s decision to start updating WebKitGTK+ means the vast majority of Linux users are now receiving updates."

to post comments

Catanzaro: An Update on WebKit Security Updates

Posted Feb 8, 2017 20:07 UTC (Wed) by fratti (subscriber, #105722) [Link] (8 responses)

Before someone claims that Debian has backported all those security fixes:
Check for yourself. They have not. I do not see a single change to the jessie packaging repo since 2015.

Catanzaro: An Update on WebKit Security Updates

Posted Feb 8, 2017 20:54 UTC (Wed) by simcop2387 (subscriber, #101710) [Link] (7 responses)

That's because the updates are in the jessie-backports and security updates repos [1]. Debian doesn't tend to update the original repo for this kind of thing. They're currently on the latest stable release according to the main webkit-gtk page[2]. Didn't check on the QT one as I'm not sure where to find it's info but I imagine it's similarly kept up to date in the other repos. The point of debian stable is that it's stable, for security fixes you add the security repo (done by default in the installer), and if you want to get backported things for features or other fixes then add the backports repo (not done by default I believe).

[1] https://packages.debian.org/source/jessie-backports/webki...
[2] https://webkitgtk.org/

Catanzaro: An Update on WebKit Security Updates

Posted Feb 8, 2017 23:05 UTC (Wed) by pabs (subscriber, #43278) [Link] (2 responses)

With Debian, security fixes are folded back into stable after point releases.

WebKit is explicitly *not* security supported in Debian:

https://sources.debian.net/src/debian-security-support/je...

Catanzaro: An Update on WebKit Security Updates

Posted Feb 9, 2017 11:30 UTC (Thu) by cortana (subscriber, #24596) [Link] (1 responses)

I find the proliferation of webkit packages rather confusing, but AIUI webkitgtk is only used by programs embedding (one hopes) trusted (local) content (on my system, gnucash, bijiben and empathy). webkit2gtk is not on that list, and appears to be used by programs that are responsible for presenting untrusted (remote) content such as epiphany, evolution, liferea, etc.

Catanzaro: An Update on WebKit Security Updates

Posted Feb 9, 2017 13:06 UTC (Thu) by jbicha (subscriber, #75043) [Link]

Sadly, empathy is in the wrong category (it handles untrusted, non-local content but hasn't been ported to webkit2 yet)

Catanzaro: An Update on WebKit Security Updates

Posted Feb 9, 2017 4:37 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link] (3 responses)

WebKitGTK+ updates are indeed in the jessie-backports repo, but they are NOT in the security repo. It's certainly Debian's prerogative to decide how and where to package its updates, but so long as the updates are not present in the stable security repo, I will continue to score it as not providing WebKit security updates.

Catanzaro: An Update on WebKit Security Updates

Posted Feb 10, 2017 10:37 UTC (Fri) by jubal (subscriber, #67202) [Link] (2 responses)

Do I understand correctly, that you're blaming Debian for the fact that you do not provide security updates in a maintainable way?

Catanzaro: An Update on WebKit Security Updates

Posted Feb 10, 2017 12:46 UTC (Fri) by ehiggs (subscriber, #90713) [Link] (1 responses)

From his blog:

https://blogs.gnome.org/mcatanzaro/2017/02/08/an-update-o...

"""
Debian does not update WebKit as a matter of policy. The latest release, Debian 8.7, is still shipping WebKitGTK+ 2.6.2. I count 184 known vulnerabilities affecting it, though that’s an overcount as we did not exclude some Mac-specific security issues from the 2015 security advisories. (Shipping ancient WebKit is not just a security problem, but a user experience problem too. Actually attempting to browse the web with WebKitGTK+ 2.6.2 is quite painful due to bugs that were fixed years ago, so please don’t try to pretend it’s “stable.”) Note that a secure version of WebKitGTK+ is available for those in the know via the backports repository, but this does no good for users who trust Debian to provide them with security updates by default without requiring difficult configuration. Debian testing users also currently have the latest 2.14.3, but you will need to switch to Debian unstable to get security updates for the foreseeable future, as testing is about to freeze.
"""

Catanzaro: An Update on WebKit Security Updates

Posted Feb 10, 2017 13:16 UTC (Fri) by jubal (subscriber, #67202) [Link]

I'm aware of this blog article, yes – it's what prompted my question.

Catanzaro: An Update on WebKit Security Updates

Posted Feb 9, 2017 7:23 UTC (Thu) by Mook (subscriber, #71173) [Link] (8 responses)

A year later (and reading both this post and the previous one, plus the comments), I still don't understand why shaming distributions is a good thing to do. The cause appears to be because upstream has breaking changes and not enough manpower to maintain stable branches, and downstream have the same lack of manpower. So nobody can do the work. It doesn't seem like telling people how bad it is would help in any way.

Of course, it appears that none of the other browser engines have enough stability guarantees either, so anybody wanting to embed a browser in their application is stuck. On Linux, at least; Trident should still work on Windows, and WebView on macOS is probably fine.

Catanzaro: An Update on WebKit Security Updates

Posted Feb 9, 2017 21:02 UTC (Thu) by drag (guest, #31333) [Link] (4 responses)

People depend on distributions for security updates. If distributions cannot or do not provide security updates then it's important that people are made aware of this. Not everybody has the knowledge or ability to do a deep dive and look at html libraries for badly maintained ones. People that value security should use distributions that do a better job at being secure.

This also highlights problems in how software in Linux ecosystem is handled.

> Of course, it appears that none of the other browser engines have enough stability guarantees either, so anybody wanting to embed a browser in their application is stuck.

The WWW is a moving target. HTML rendering engines are insanely complex and they are exposed to a changing and evolving threat as well as changing and evolving standards. Updates and changes need to happen.

In Linux WebkitGTK+ is what you want to use currently. It had issues with updates that broke things, but they seem to have been resolved. Hopefully other libraries for non-gtk applications will catch up.

Catanzaro: An Update on WebKit Security Updates

Posted Feb 9, 2017 21:07 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

Well probably qtwebengine is also a option. Also I don't know how good mozilla-based (or whatever else there is) engines are at being up to date.

Catanzaro: An Update on WebKit Security Updates

Posted Feb 10, 2017 1:30 UTC (Fri) by jbicha (subscriber, #75043) [Link] (1 responses)

The Mozilla equivalent (SpiderMonkey) isn't maintained well at all.

The latest release is 10 months old. It corresponds with Firefox 45.0 ESR, but because the latest ESR is 45.7, it has many known security vulnerabilities. Previous SpiderMonkey releases weren't handled any better.

Catanzaro: An Update on WebKit Security Updates

Posted Feb 10, 2017 5:17 UTC (Fri) by Mook (subscriber, #71173) [Link]

SpiderMonkey is just the JavaScript engine; my understanding is that there is currently no usable web browser embedding API supported upstream (but they hope that Servo will be able to do it via Chromium Embedded Framework-compatible APIs some day).

Catanzaro: An Update on WebKit Security Updates

Posted Feb 10, 2017 5:27 UTC (Fri) by Mook (subscriber, #71173) [Link]

Ah; I hadn't kept close enough attention to realize that WebkitGTK+ had resolved their issues; that's good news. I thought the problem was that they changed GTK+ versions though, and orphaned all their previous users?

And while the WWW is indeed a moving target, as long as the browser stays secure a LTS-style embedding isn't so bad. Often it only needs to correctly render specific content (as long as other content remains secure); also, people managed to do it with IE6 for years. Of course, keeping that branch alive is unlikely to be very enjoyable, so it's more likely to occur in commercial settings where people do it for reasons other than the enjoyment of coding.

Catanzaro: An Update on WebKit Security Updates

Posted Feb 10, 2017 15:36 UTC (Fri) by mcatanzaro (subscriber, #93033) [Link] (2 responses)

We maintain stable branches for roughly six months. After that, you need to move on to the next stable branch. They upgrades are always API and ABI compatible*, and new versions of dependencies are expected to be at least three years old. We want to avoid trouble for any of the distributions that are actually currently shipping our updates.

* Exception: there is an undocumented unstable DOM API, which does not provide API or ABI stability even within a stable release series. It was a bad idea, you should not use it, and it will no longer be present at all in 2.16.

Catanzaro: An Update on WebKit Security Updates

Posted Feb 13, 2017 9:46 UTC (Mon) by mgallien (guest, #94191) [Link] (1 responses)

As soon as you put an exception on your stability guarantees, you get the Debian way of not putting updates in stable. There will be possibility to break software using your library. This is a no go in stable. I for one would like to not break a Debian box just because a security bug has been fixed.

Catanzaro: An Update on WebKit Security Updates

Posted Feb 14, 2017 1:09 UTC (Tue) by zlynx (guest, #2285) [Link]

Hello, hypothetical developer here! I use ptrace with hard coded offsets to link my code into your library. You recompiled it and broke my program. Please fix.

See, there have to be limits on what can be supported. An undocumented, hidden layer of code is fair game in my mind, on the level of my first paragraph.