September 20, 2018

WebKitGTK+ 2.22.1 released!

by The WebKitGTK+ Project

This is the first bug fix release in the stable 2.22 series.

What’s new in the WebKitGTK+ 2.22.1 release?

  • Fix printing in landscape.
  • Fix the build in several platforms: s390x, ppc64le, armv7hl.
  • Fix the build with a11y disabled.
  • Fix the build with video disabled.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

September 20, 2018 12:00 AM



September 03, 2018

WebKitGTK+ 2.22.0 released!

by The WebKitGTK+ Project

This is the first stable release in the 2.22 series.

Highlights of the WebKitGTK+ 2.22.0 release

  • New JavaScriptCore GLib API.
  • Switched to use complex text code path unconditionally.
  • Added playbin3 support to GStreamer media backend
  • Support for WebDriver advance user insteraction commands.
  • Default option menu implementation now uses a GtkTreeView.

For more details about all the changes included in WebKitGTK+ 2.22 see the NEWS file that is included in the tarball.

Thanks to all the contributors who made possible this release.

September 03, 2018 12:00 AM



August 24, 2018

WebKitGTK+ 2.21.92 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.22 series.

What’s new in the WebKitGTK+ 2.21.92 release?

  • Add new API to inject/register user content in isolated worlds.
  • Add more API to JSCException to handle column number, convert exception to string, get the exception backtrace, create exceptions with a custom error name and report exception message with full details.
  • Fix excessive CPU usage when getting the process memory footprint.
  • Fix several crashes and rendering issues.
  • Translation updates: Polish

Thanks to all the contributors who made possible this release.

August 24, 2018 12:00 AM



August 16, 2018

WebKitGTK+ 2.21.91 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.22 series.

What’s new in the WebKitGTK+ 2.21.91 release?

  • Add enable-media-capabilities setting.
  • Stop pushing buffers when seeking status changes in media player.
  • Fix rendering of theme styled buttons.
  • Fix several crashes and rendering issues.
  • Translation updates: Brazilian Portuguese.

Thanks to all the contributors who made possible this release.

August 16, 2018 12:00 AM



August 13, 2018

WebKitGTK+ 2.20.5 released!

by The WebKitGTK+ Project

This is a bug fix release in the stable 2.20 series.

What’s new in the WebKitGTK+ 2.20.5 release?

  • Fix rendering artifacts in some web sites due to a bug introduced in 2.20.4.

Thanks to all the contributors who made possible this release.

August 13, 2018 12:00 AM



August 07, 2018

WebKitGTK+ and WPE WebKit Security Advisory WSA-2018-0006

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+ and WPE WebKit.

  • CVE-2018-4246
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.1.
    • Credit to OSS-Fuzz.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A type confusion issue was addressed with improved memory handling.
  • CVE-2018-4261
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.2.
    • Credit to Omair working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2018-4262
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.2.
    • Credit to Mateusz Krzywicki working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2018-4263
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.2.
    • Credit to Arayz working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2018-4264
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.2.
    • Credit to OSS-Fuzz, Yu Zhou and Jundong Xie of Ant-financial Light- Year Security Lab.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2018-4265
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.2.
    • Credit to cc working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2018-4266
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.2.
    • Credit to OSS-Fuzz.
    • A malicious website may be able to cause a denial of service. A race condition was addressed with additional validation.
  • CVE-2018-4267
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.2.
    • Credit to Arayz of Pangu team working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2018-4270
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.2.
    • Credit to OSS-Fuzz.
    • Processing maliciously crafted web content may lead to an unexpected application crash. A memory corruption issue was addressed with improved memory handling.
  • CVE-2018-4271
    • Versions affected: WebKitGTK+ before 2.20.2.
    • Credit to OSS-Fuzz.
    • Processing maliciously crafted web content may lead to an unexpected application crash. A memory corruption issue was addressed with improved input validation.
  • CVE-2018-4272
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.2.
    • Credit to OSS-Fuzz.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2018-4273
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.2.
    • Credit to OSS-Fuzz.
    • Processing maliciously crafted web content may lead to an unexpected application crash. A memory corruption issue was addressed with improved input validation.
  • CVE-2018-4278
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.2.
    • Credit to Jun Kokatsu (@shhnjk).
    • A malicious website may exfiltrate audio data cross-origin. Sound fetched through audio elements may be exfiltrated cross-origin. This issue was addressed with improved audio taint tracking.
  • CVE-2018-4284
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.2.
    • Credit to OSS-Fuzz.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A type confusion issue was addressed with improved memory handling.
  • CVE-2018-12911
    • Versions affected: WebKitGTK+ before 2.20.4 and WPE WebKit before 2.20.2.
    • Credit to Yu Haiwan.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A buffer overflow issue was addressed with improved memory handling.

We recommend updating to the latest stable versions of WebKitGTK+ and WPE WebKit. It is the best way to ensure that you are running safe versions of WebKit. Please check our websites for information about the latest stable releases.

Further information about WebKitGTK+ and WPE WebKit security advisories can be found at: https://webkitgtk.org/security.html or https://wpewebkit.org/security/.

August 07, 2018 12:00 AM



August 06, 2018

WebKitGTK+ 2.20.4 released!

by The WebKitGTK+ Project

This is a bug fix release in the stable 2.20 series.

What’s new in the WebKitGTK+ 2.20.4 release?

Thanks to all the contributors who made possible this release.

August 06, 2018 12:00 AM



July 21, 2018

On Flatpak Nightlies

by Michael Catanzaro

Here’s a little timeline of some fun we had with the GNOME master Flatpak runtime last week:

  • Tuesday, July 10: a bad runtime build is published.  Trying to start any application results in error while loading shared libraries: libdw.so.1: cannot open shared object file: No such file or directory. Problem is the library is present in org.gnome.Sdk instead of org.gnome.Platform, where it is required.
  • Thursday, July 12:  the bug is reported on WebKit Bugzilla (since it broke Epiphany Technology Preview)
  • Saturday, July 14: having returned from GUADEC, I notice the bug report and bisect the issue to a particular runtime build. Mathieu Bridon fixes the issue in the freedesktop SDK and opens a merge request.
  • Monday, July 16: Mathieu’s fix is committed. We now have to wait until Tuesday for the next build.
  • Tuesday, Wednesday, and Thursday: we deal with various runtime build failures. Each day, we get a new build log and try to fix whatever build failure is reported. Then, we wait until the next day and see what the next failure is. (I’m not aware of any way to build the runtime locally. No doubt it’s possible somehow, but there are no instructions for doing so.)
  • Friday, July 20: we wait. The build has succeeded and the log indicates the build has been published, but it’s not yet available via flatpak update
  • Saturday, July 21: the successful build is now available. The problem is fixed.

As far as I know, it was not possible to run any nightly applications during this two week period, except developer applications like Builder that depend on org.gnome.Sdk instead of the normal org.gnome.Platform. If you used Epiphany Technology Preview and wanted a functioning web browser, you had to run arcane commands to revert to the last good runtime version.

This multi-week response time is fairly typical for us. We need to improve our workflow somehow. It would be nice to be able to immediately revert to the last good build once a problem has been identified, for instance.

Meanwhile, even when the runtime is working fine, some apps have been broken for months without anyone noticing or caring. Perhaps it’s time for a rethink on how we handle nightly apps. It seems likely that only a few apps, like Builder and Epiphany, are actually being regularly used. The release team has some hazy future plans to take over responsibility for the nightly apps (but we have to take over the runtimes first, since those are more important), and we’ll need to somehow avoid these issues when we do so. Having some form of notifications for failed builds would be a good first step.

P.S. To avoid any possible misunderstandings: the client-side Flatpak technology itself is very good. It’s only the server-side infrastructure that is problematic here. Clearly we have a lot to fix, but it won’t require any changes in Flatpak.

by Michael Catanzaro at July 21, 2018 02:12 PM



July 20, 2018

WebKitGTK+ 2.21.5 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.22 series.

What’s new in the WebKitGTK+ 2.21.5 release?

  • Add API to evaluate code in a new object to JavaScriptCore GLib API.
  • Add API to check for syntax errors in given code to JavaScriptCore GLib API.
  • Update jsc_context_evaluate_with_source_uri() to receive also a starting line number.
  • Add API to allow creating variadic functions to JavaScriptCore GLib API.
  • Add –host option to WebDriver process.
  • Handle acceptInsecureCertificates capability in WebDriver.
  • Fix video freezes when GStreamerGL is not installed.
  • Fix several crashes and rendering issues.
  • Translation updates: Ukrainian.

Thanks to all the contributors who made possible this release.

July 20, 2018 12:00 AM



June 13, 2018

WebKitGTK+ and WPE WebKit Security Advisory WSA-2018-0005

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+ and WPE WebKit.

  • CVE-2018-4190
    • Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before 2.20.1.
    • Credit to Jun Kokatsu (@shhnjk).
    • Impact: Visiting a maliciously crafted website may leak sensitive data. Description: Credentials were unexpectedly sent when fetching CSS mask images. This was addressed by using a CORS-enabled fetch method.
  • CVE-2018-4192
    • Versions affected: WebKitGTK+ before 2.20.1.
    • Credit to Markus Gaasedelen, Nick Burnett, and Patrick Biernat of Ret2 Systems, Inc working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A race condition was addressed with improved locking.
  • CVE-2018-4199
    • Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before 2.20.1.
    • Credit to Alex Plaskett, Georgi Geshev, Fabi Beterke, and Nils of MWR Labs working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A buffer overflow issue was addressed with improved memory handling.
  • CVE-2018-4201
    • Versions affected: WebKitGTK+ before 2.20.1.
    • Credit to an anonymous researcher.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4214
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to OSS-Fuzz.
    • Impact: Processing maliciously crafted web content may lead to an unexpected application crash. Description: A memory corruption issue was addressed with improved input validation.
  • CVE-2018-4218
    • Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before 2.20.1.
    • Credit to Natalie Silvanovich of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4222
    • Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before 2.20.1.
    • Credit to Natalie Silvanovich of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: An out-of-bounds read was addressed with improved input validation.
  • CVE-2018-4232
    • Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before 2.20.1.
    • Credit to Aymeric Chaib.
    • Impact: Visiting a maliciously crafted website may lead to cookies being overwritten. Description: A permissions issue existed in the handling of web browser cookies. This issue was addressed with improved restrictions.
  • CVE-2018-4233
    • Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before 2.20.1.
    • Credit to Samuel Groß (@5aelo) working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-11646
    • Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before 2.20.1.
    • Credit to Mishra Dhiraj.
    • Maliciously crafted web content could trigger an application crash in WebKitFaviconDatabase, caused by mishandling unexpected input.
  • CVE-2018-11712
    • Versions affected: WebKitGTK+ 2.20.0 and 2.20.1.
    • Credit to Metrological Group B.V.
    • The libsoup network backend of WebKit failed to perform TLS certificate verification for WebSocket connections.
  • CVE-2018-11713
    • Versions affected: WebKitGTK+ before 2.20.0 or without libsoup 2.62.0.
    • Credit to Dirkjan Ochtman.
    • The libsoup network backend of WebKit unexpectedly failed to use system proxy settings for WebSocket connections. As a result, users could be deanonymized by crafted web sites via a WebSocket connection.
  • CVE-2018-12293
    • Versions affected: WebKitGTK+ before 2.20.3 and WPE WebKit before 2.20.1.
    • Credit to ADlab of Venustech.
    • Maliciously crafted web content could achieve a heap buffer overflow in ImageBufferCairo by exploiting multiple integer overflow issues.
  • CVE-2018-12294
    • Versions affected: WebKitGTK+ before 2.20.2.
    • Credit to ADlab of Venustech.
    • Maliciously crafted web content could trigger a use-after-free of a TextureMapperLayer object.

We recommend updating to the latest stable versions of WebKitGTK+ and WPE WebKit. It is the best way to ensure that you are running a safe version of WebKit. Please check our websites for information about the latest stable releases.

Further information about WebKitGTK+ and WPE WebKit security advisories can be found at https://webkitgtk.org/security.html or https://wpewebkit.org/security/.

June 13, 2018 12:00 AM



June 12, 2018

WebKitGTK+ 2.21.4 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.22 series.

What’s new in the WebKitGTK+ 2.21.4 release?

  • Switch to use a popup window with a tree view instead of a menu for option menu default implementation.
  • Add API to run javascript from a WebKitWebView in an isolated world.
  • Fix UI process crash in WebKitFaviconDatabase when pageURL is unset.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

June 12, 2018 12:00 AM



June 11, 2018

WebKitGTK+ 2.20.3 released!

by The WebKitGTK+ Project

This is a bug fix release in the stable 2.20 series.

What’s new in the WebKitGTK+ 2.20.3 release?

  • Fix installation directory of API documentation.
  • Disable Gigacage if mmap fails to allocate in Linux.
  • Add user agent quirk for paypal website.
  • Properly detect compiler flags, needed libs, and fallbacks for usage of 64-bit atomic operations.
  • Fix a network process crash when trying to get cookies of about:blank page.
  • Fix UI process crash when closing the window under Wayland.
  • Fix several crashes and rendering issues.
  • Security fixes: CVE-2018-4190, CVE-2018-4199, CVE-2018-4218, CVE-2018-4222, CVE-2018-4232, CVE-2018-4233, CVE-2018-4246, CVE-2018-11646.

Thanks to all the contributors who made possible this release.

June 11, 2018 12:00 AM



June 04, 2018

Security vulnerability in Epiphany Technology Preview

by Michael Catanzaro

If you use Epiphany Technology Preview, please update immediately and ensure you have revision 3.29.2-26 or newer. We discovered and resolved a vulnerability that allowed websites to access internal Epiphany features and thereby exfiltrate passwords from the password manager. We apologize for this oversight.

The unstable Epiphany 3.29.2 release is the only affected release. Epiphany 3.29.1 is not affected. Stable releases, including Epiphany 3.28, are also not affected.

There is no reason to believe that the issue was discovered or exploited by any attackers, but you might wish to change your passwords if you are concerned.

by Michael Catanzaro at June 04, 2018 11:00 PM



May 28, 2018

WebKitGTK+ 2.21.3 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.22 series.

What’s new in the WebKitGTK+ 2.21.3 release?

  • Ensure memory monitor properly notifies all child processes.
  • Add maximize, minimize and fullscreen window commands to WebDriver.
  • Fix a network process crash when trying to get cookies of about:blank page.
  • Fix UI process crash when closing the window under Wayland.
  • Disable Gigacage if mmap fails to allocate in Linux.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

May 28, 2018 12:00 AM



May 27, 2018

Thoughts on Flatpak after four months of Epiphany Technology Preview

by Michael Catanzaro

It’s been four months since I announced Epiphany Technology Preview — which I’ve been using as my main browser ever since — and five months since I announced the availability of a stable channel via Flatpak. For the most part, it’s been a good experience. Having the latest upstream development code for everything is wonderful and makes testing very easy. Any user can painlessly download and install either the latest stable version or the bleeding-edge development version on any Linux system, regardless of host dependencies, either via a couple clicks in GNOME Software or one command in the terminal. GNOME Software keeps it updated, so I always have a recent version. Thanks to this, I’m often noticing problems shortly after they’re introduced, rather than six months later, as was so often the case for me in the past. Plus, other developers can no longer complain that there’s a problem with my local environment when I report a bug they can’t reproduce, because Epiphany Technology Preview is a canonical distribution environment, a ground truth of sorts.

There have been some rough patches where Epiphany Technology Preview was not working properly — sometimes for several days — due to various breaking changes, and the long time required to get a successful SDK build when it’s failing. For example, multimedia playback was broken for all of last week, due to changes in how the runtime is built. H.264 video is still broken, since the relevant Flatpak extension is only compatible with the 3.28 runtime, not with master. Opening files was broken for a while due to what turned out to be a bug in mutter that was causing the OpenURI portal to crash. I just today found another bug where closing a portal while visiting Slack triggered a gnome-shell crash. For the most part, these sorts of problems are expected by testers of unstable nightly software, though I’m concerned about the portal bugs because these affect stable users too. Anyway, these are just bugs, and all software has bugs: they get fixed, nothing special.

So my impression of Flatpak is still largely positive. Flatpak does not magically make our software work properly in all host environments, but it hugely reduces the number of things that can go wrong on the host system. In recent years, I’ve seen users badly break Epiphany in various ways, e.g. by installing custom mimeinfo or replacing the network backend. With Flatpak, either of these would require an incredible amount of dedicated effort. Without a doubt, Flatpak distribution is more robust to user error. Another advantage is that we get the latest versions of OS dependencies, like GStreamer, libsoup, and glib-networking, so we can avoid the many bugs in these components that have been fixed in the years since our users’ LTS distros froze the package versions. I appreciate the desire of LTS distros to provide stability for users, but at the same time, I’m not impressed when users report issues with the browser that we fixed two years ago in one dependency or another. Flatpak is an excellent compromise solution to this problem: the LTS distro retains an LTS core, but specific applications can use newer dependencies from the Flatpak runtime.

But there is one huge downside to using Flatpak: we lose crash reports. It’s at best very difficult — and often totally impossible — to investigate crashes when using Flatpak, and that’s frankly more important than any of the gains I mention above. For example, today Epiphany Technology Preview is crashing pretty much constantly. It’s surely a bug in WebKit, but that’s all I can figure out. The way to get a backtrace from a crashing app in flatpak is to use coredumpctl to manually dump the core dump to disk, then launch a bash shell in the flatpak environment and manually load it up in gdb. The process is manual, old-fashioned, primitive, and too frustrating for me by a lot, so I wrote a little pyexpect script to automate this process for Epiphany, thinking I could eventually generalize it into a tool that would be useful for other developers. It’s a horrible hack, but it worked pretty well the day I tested it. I haven’t seen it work since. Debuginfo seems to be constantly broken, so I only see a bunch of ???s in my backtraces, and how are we supposed to figure out how to debug that? So I have no way to debug or fix the WebKit bug, because I can’t get a backtrace. The broken, inconsistent, or otherwise-unreliable debuginfo is probably just some bug that will be fixed eventually (and which I half suspect may be related to our recent freedesktop SDK upgrade. Update: Alex has debugged the debuginfo problem and it looks like that’s on track to be solved), but even once it is, we’re back to square one: it’s still too much effort to get the backtrace, relative to developing on the host system, and that’s a hard problem to solve. It requires tools that do not exist, and for which we have no plans to create, or even any idea of how to create them.

This isn’t working. I need to be able to effortlessly get a backtrace out of my application, with no or little more effort than running coredumpctl gdb as I would without Flatpak in the way. Every time I see Epiphany or WebKit crash, knowing I can do nothing to debug or investigate, I’m very sorely tempted to switch back to using Fedora’s Epiphany, or good old JHBuild. (I can’t promote BuildStream here, because BuildStream has the same problem.)

So the developer experience is just not good, but set that aside: the main benefits of Flatpak are for users, not developers, after all. Now, what if users run into a crash, how can they report the bug? Crash reports are next to useless without a backtrace, and wise developers refuse to look at crash reports until a quality backtrace has been posted. So first we need to fix the developer experience to work properly, but even then, it’s not enough: we need an automatic crash reporter, along the lines of ABRT or apport, to make reporting crashes realistically-achievable for users, as it already is for distro-packaged apps. But this is a much harder problem to solve. Such a tool will require integration with coredumpctl, and I have not the faintest clue how we could go about making coredumpctl support container environments. Yet without this, we’re asking application developers to give up their most valuable data — crash reports — in order to use Flatpak.

Eventually, if we don’t solve crash reporting, Epiphany’s experiment with Flatpak will have to come to an end, because that’s more important to me than the (admittedly-tremendous) benefits of Flatpak. I’m still hopeful that the ingenuity of the Flatpak community will find some solutions. We’ll see how this goes.

by Michael Catanzaro at May 27, 2018 11:39 PM



May 21, 2018

WebKitGTK+ 2.21.2 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.22 series.

What’s new in the WebKitGTK+ 2.21.2 release?

  • Remove resource load statistics API, it’s not ready yet.
  • Add initial implementation of WebDriver advance user insteraction commands.
  • Add introspectable alternatives for functions using vargars to JavaScriptCore GLib API.
  • Implement MouseEvent.buttons.
  • Do TLS error checking on GTlsConnection::accept-certificate to finish the load earlier in case of errors.
  • Fix downloads started by context menu failing in some websites due to missing user agent HTTP header.
  • Avoid painting backing stores for zero-opacity layers.
  • Fix the installation path of API documentation.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

May 21, 2018 12:00 AM



May 07, 2018

WebKitGTK+ Security Advisory WSA-2018-0004

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2018-4121
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to Natalie Silvanovich of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4200
    • Versions affected: WebKitGTK+ before 2.20.2.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A memory corruption issue was addressed with improved state management.
  • CVE-2018-4204
    • Versions affected: WebKitGTK+ before 2.20.1.
    • Credit to Richard Zhu (fluorescence) working with Trend Micro’s Zero Day Initiative, found by OSS-Fuzz.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A memory corruption issue was addressed with improved memory handling.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

May 07, 2018 12:00 AM



WebKitGTK+ 2.20.2 released!

by The WebKitGTK+ Project

This is a bug fix release in the stable 2.20 series.

What’s new in the WebKitGTK+ 2.20.2 release?

  • Do TLS error checking on GTlsConnection::accept-certificate to finish the load earlier in case of errors.
  • Properly close the connection to the nested wayland compositor in the Web Process.
  • Avoid painting backing stores for zero-opacity layers.
  • Fix downloads started by context menu failing in some websites due to missing user agent HTTP header.
  • Fix video unpause when GStreamerGL is disabled.
  • Fix several GObject introspection annotations.
  • Update user agent quiks to fix Outlook.com and Chase.com.
  • Fix several crashes and rendering issues.
  • Security fixes: CVE-2018-4200.

Thanks to all the contributors who made possible this release.

May 07, 2018 12:00 AM



April 18, 2018

WebKitGTK+ 2.21.1 released!

by The WebKitGTK+ Project

This is the first development release leading toward 2.22 series.

What’s new in the WebKitGTK+ 2.21.1 release?

  • Add initial JavaScriptCore GLib API.
  • Use JavaScriptCore GLib API in WebKit layer and deprecate most of the DOM bindings API as well as methods using the JavaScriptCore C API.
  • Switch to use complex text code path unconditionally.
  • Properly close the connection to the Wayland nested compositor in the WebProcess.
  • Implement support for Graphics ARIA roles.
  • Add playbin3 support to GStreamer media backend.
  • Fix a deadlock when destroying the media player in non accelerated compositing mode.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

April 18, 2018 12:00 AM



April 10, 2018

WebKitGTK+ 2.20.1 released!

by The WebKitGTK+ Project

This is the first bug fix release in the stable 2.20 series.

What’s new in the WebKitGTK+ 2.20.1 release?

  • Improve error message when Gigacage cannot allocate virtual memory.
  • Add missing WebKitWebProcessEnumTypes.h to webkit-web-extension.h.
  • Improve web process memory monitor thresholds.
  • Fix a web process crash when the web view is created and destroyed quickly.
  • Fix a network process crash when load is cancelled while searching for stored HTTP auth credentials.
  • Fix the build when ENABLE_VIDEO, ENABLE_WEB_AUDIO and ENABLE_XSLT are disabled.
  • Fix several crashes and rendering issues.
  • Translation updates: Brazilian Portuguese, Czech.

Thanks to all the contributors who made possible this release.

April 10, 2018 12:00 AM



April 04, 2018

WebKitGTK+ Security Advisory WSA-2018-0003

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2018-4101
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to Yuan Deng of Ant-financial Light-Year Security Lab.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4113
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to OSS-Fuzz.
    • Impact: Unexpected interaction with indexing types causing an ASSERT failure. Description: An array indexing issue existed in the handling of a function in JavaScriptCore. This issue was addressed through improved checks.
  • CVE-2018-4114
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to OSS-Fuzz.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4117
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to an anonymous researcher.
    • Impact: A malicious website may exfiltrate data cross-origin. Description: A cross-origin issue existed with the fetch API. This was addressed through improved input validation.
  • CVE-2018-4118
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to Jun Kokatsu (@shhnjk).
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4119
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to an anonymous researcher working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4120
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to Hanming Zhang (@4shitak4) of Qihoo 360 Vulcan Team.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4122
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to WanderingGlitch of Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4125
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to WanderingGlitch of Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4127
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to an anonymous researcher working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4128
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to Zach Markley.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4129
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to likemeng of Baidu Security Lab working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4133
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to Anton Lopanitsyn of Wallarm, Linus Särud of Detectify (detectify.com), Yuji Tounai of NTT Communications Corporation.
    • Impact: Visiting a maliciously crafted website may lead to a cross- site scripting attack. Description: A cross-site scripting issue existed in WebKit. This issue was addressed with improved URL validation.
  • CVE-2018-4146
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to OSS-Fuzz.
    • Impact: Processing maliciously crafted web content may lead to a denial of service. Description: A memory corruption issue was addressed through improved input validation.
  • CVE-2018-4161
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to WanderingGlitch of Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4162
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to WanderingGlitch of Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4163
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to WanderingGlitch of Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4165
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to Hanming Zhang (@4shitak4) of Qihoo 360 Vulcan Team.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

April 04, 2018 12:00 AM



March 18, 2018

Web Engines Hackfest 2014

by Philippe Normand

Last week I attended the Web Engines Hackfest. The event was sponsored by Igalia (also hosting the event), Adobe and Collabora.

As usual I spent most of the time working on the WebKitGTK+ GStreamer backend and Sebastian Dröge kindly joined and helped out quite a bit, make sure to read …

by Philippe Normand at March 18, 2018 09:18 AM



March 12, 2018

WebKitGTK+ 2.20.0 released!

by The WebKitGTK+ Project

This is the first stable release in the 2.20 series.

Highlights of the WebKitGTK+ 2.20.0 release

  • New API to retrieve and delete cookies with WebKitCookieManager.
  • New web process API to detect when form is submitted via JavaScript.
  • Several improvements and fixes in the touch/gestures support.
  • Support for the “system” CSS font family.
  • Complex text rendering improvements and fixes.
  • Added a low power mode.
  • More complete and spec compliant WebDriver implementation.

For more details about all the changes included in WebKitGTK+ 2.20 see the NEWS file that is included in the tarball.

Thanks to all the contributors who made possible this release.

March 12, 2018 12:00 AM



March 06, 2018

WebKitGTK+ 2.19.92 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.20 series.

What’s new in the WebKitGTK+ 2.19.92 release?

  • Ensure DNS prefetching cannot be re-enabled if disabled by settings.
  • Fix seek sometimes not working.
  • Fix rendering of emojis that were using the wrong scale factor in some cases.
  • Fix rendering of combining enclosed keycap.
  • Fix rendering scale of some layers in HiDPI.
  • Fix a crash in Wayland when closing the web view.
  • Fix crashes upower crashes when running inside a chroot or on systems with broken dbus/upower.
  • Fix memory leaks in GStreamer media backend when using GStreamer 1.14.
  • Fix the build with Enchant 2.x.
  • Fix several crashes and rendering issues.
  • Translation updates: Indonesian.

Thanks to all the contributors who made possible this release.

March 06, 2018 12:00 AM



February 21, 2018

WebKitGTK+ 2.19.91 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.20 series.

What’s new in the WebKitGTK+ 2.19.91 release?

  • Add ENABLE_ADDRESS_SANITIZER to make it easier to build with asan support.
  • Fix a crash a under Wayland when using mesa software rasterization.
  • Make fullscreen video work again.
  • Fix handling of missing GStreamer elements.
  • Fix rendering when webm video is played twice.
  • Fix kinetic scrolling sometimes jumping around.
  • Fix build with ICU configured without collation support.
  • Fix several crashes and rendering issues.
  • Translation updates: Polish.

Thanks to all the contributors who made possible this release.

February 21, 2018 12:00 AM



February 17, 2018

On Compiling WebKit (now twice as fast!)

by Michael Catanzaro

Are you tired of waiting for ages to build large C++ projects like WebKit? Slow headers are generally the problem. Your C++ source code file #includes a few headers, all those headers #include more, and those headers #include more, and more, and more, and since it’s C++ a bunch of these headers contain lots of complex templates to slow down things even more. Not fun.

It turns out that much of the time spent building large C++ projects is effectively spent parsing the same headers again and again, over, and over, and over, and over, and over….

There are three possible solutions to this problem:

  • Shred your CPU and buy a new one that’s twice as fast.
  • Use C++ modules: import instead of #include. This will soon become the best solution, but it’s not standardized yet. For WebKit’s purposes, we can’t use it until it works the same in MSVCC, Clang, and three-year-old versions of GCC. So it’ll be quite a while before we’re able to take advantage of modules.
  • Use unified builds (sometimes called unity builds).

WebKit has adopted unified builds. This work was done by Keith Miller, from Apple. Thanks, Keith! (If you’ve built WebKit before, you’ll probably want to say that again: thanks, Keith!)

For a release build of WebKitGTK+, on my desktop, our build times used to look like this:

real 62m49.535s
user 407m56.558s
sys 62m17.166s

That was taken using WebKitGTK+ 2.17.90; build times with any 2.18 release would be similar. Now, with trunk (or WebKitGTK+ 2.20, which will be very similar), our build times look like this:

real 33m36.435s
user 214m9.971s
sys 29m55.811s

Twice as fast.

The approach is pretty simple: instead of telling the compiler to build the original C++ source code files that developers see, we instead tell the compiler to build unified source files that look like this:

// UnifiedSource1.cpp
#include "CSSValueKeywords.cpp"
#include "ColorData.cpp"
#include "HTMLElementFactory.cpp"
#include "HTMLEntityTable.cpp"
#include "JSANGLEInstancedArrays.cpp"
#include "JSAbortController.cpp"
#include "JSAbortSignal.cpp"
#include "JSAbstractWorker.cpp"

Since files are included only once per translation unit, we now have to parse the same headers only once for each unified source file, rather than for each individual original source file, and we get a dramatic build speedup. It’s pretty terrible, yet extremely effective.

Now, how many original C++ files should you #include in each unified source file? To get the fastest clean build time, you would want to #include all of your C++ source files in one, that way the compiler sees each header only once. (Meson can do this for you automatically!) But that causes two problems. First, you have to make sure none of the files throughout your entire codebase use conflicting variable names, since the static keyword and anonymous namespaces no longer work to restrict your definitions to a single file. That’s impractical in a large project like WebKit. Second, because there’s now only one file passed to the compiler, incremental builds now take as long as clean builds, which is not fun if you are a WebKit developer and actually need to make changes to it. Unifying more files together will always make incremental builds slower. After some experimentation, Apple determined that, for WebKit, the optimal number of files to include together is roughly eight. At this point, there’s not yet much negative impact on incremental builds, and past here there are diminishing returns in clean build improvement.

In WebKit’s implementation, the files to bundle together are computed automatically at build time using CMake black magic. Adding a new file to the build can change how the files are bundled together, potentially causing build errors in different files if there are symbol clashes. But this is usually easy to fix, because only files from the same directory are bundled together, so random unrelated files will never be built together. The bundles are always the same for everyone building the same version of WebKit, so you won’t see random build failures; only developers who are adding new files will ever have to deal with name conflicts.

To significantly reduce name conflicts, we now limit the scope of using statements. That is, stuff like this:

using namespace JavaScriptCore;
namespace WebCore {
//...
}

Has been changed to this:

namespace WebCore {
using namespace JavaScriptCore;
// ...
}

Some files need to be excluded due to unsolvable name clashes. For example, files that include X11 headers, which contain lots of unnamespaced symbols that conflict with WebCore symbols, don’t really have any chance. But only a few files should need to be excluded, so this does not have much impact on build time. We’ve also opted to not unify most of the GLib API layer, so that we can continue to use conventional GObject names in our implementation, but again, the impact of not unifying a few files is minimal.

We still have some room for further performance improvement, because some significant parts of the build are still not unified, including most of the WebKit layer on top. But I suspect developers who have to regularly build WebKit will already be quite pleased.

by Michael Catanzaro at February 17, 2018 07:07 PM



February 16, 2018

On Python Shebangs

by Michael Catanzaro

So, how do you write a shebang for a Python program? Let’s first set aside the python2/python3 issue and focus on whether to use env. Which of the following is correct?

#!/usr/bin/env python
#!/usr/bin/python

The first option seems to work in all environments, but it is banned in popular distros like Fedora (and I believe also Debian, but I can’t find a reference for this). Using env in shebangs is dangerous because it can result in system packages using non-system versions of python. python is used in so many places throughout modern systems, it’s not hard to see how using #!/usr/bin/env in an important package could badly bork users’ operating systems if they install a custom version of python in /usr/local. Don’t do this.

The second option is broken too, because it doesn’t work in BSD environments. E.g. in FreeBSD, python is installed in /usr/local/bin. So FreeBSD contributors have been upstreaming patches to convert #!/usr/bin/python shebangs to #!/usr/bin/env python. Meanwhile, Fedora has begun automatically rewriting #!/usr/bin/env python to #!/usr/bin/python, but with a warning that this is temporary and that use of #!/usr/bin/env python will eventually become a fatal error causing package builds to fail.

So obviously there’s no way to write a shebang that will work for both major Linux distros and major BSDs. #!/usr/bin/env python seems to work today, but it’s subtly very dangerous. Lovely. I don’t even know what to recommend to upstream projects.

Next problem: python2 versus python3. By now, we should all be well-aware of PEP 394. PEP 394 says you should never write a shebang like this:

#!/usr/bin/env python
#!/usr/bin/python

unless your python script is compatible with both python2 and python3, because you don’t know what version you’re getting. Your python script is almost certainly not compatible with both python2 and python3 (and if you think it is, it’s probably somehow broken, because I doubt you regularly test it with both). Instead, you should write the shebang like this:

#!/usr/bin/env python2
#!/usr/bin/python2
#!/usr/bin/env python3
#!/usr/bin/python3

This works as long as you only care about Linux and BSDs. It doesn’t work on macOS, which provides /usr/bin/python and /usr/bin/python2.7, but still no /usr/bin/python2 symlink, even though it’s now been six years since PEP 394. It’s hard to understate how frustrating this is.

So let’s say you are WebKit, and need to write a python script that will be truly cross-platform. How do you do it? WebKit’s scripts are only needed (a) during the build process or (b) by developers, so we get a pass on the first problem: using /usr/bin/env should be OK, because the scripts should never be installed as part of the OS. Using #!/usr/bin/env python — which is actually what we currently do — is unacceptable, because our scripts are python2 and that’s broken on Arch, and some of our developers use that. Using #!/usr/bin/env python2 would be dead on arrival, because that doesn’t work on macOS. Seems like the option that works for everyone is #!/usr/bin/env python2.7. Then we just have to hope that the Python community sticks to its promise to never release a python2.8 (which seems likely).

…yay?

by Michael Catanzaro at February 16, 2018 08:21 PM



February 05, 2018

WebKitGTK+ 2.19.90 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.20 series.

What’s new in the WebKitGTK+ 2.19.90 release?

  • WebSockets use system proxy settings now (requires libsoup 2.61.90).
  • Show the context menu on long-press gesture.
  • Add support for Shift + mouse scroll to scroll horizontally.
  • Fix zoom gesture to actually zoom instead of changing the page scale.
  • Implement support for Graphics ARIA roles.
  • Make sleep inhibitors work under Flatpak.
  • Add get element CSS value command to WebDriver.
  • Fix a crash aftter a swipe gesture.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

February 05, 2018 12:00 AM



January 24, 2018

Announcing Epiphany Technology Preview

by Michael Catanzaro

If you use macOS, the best way to use a recent development snapshot of WebKit is surely Safari Technology Preview. But until now, there’s been no good way to do so on Linux, short of running a development distribution like Fedora Rawhide.

Enter Epiphany Technology Preview. This is a nightly build of Epiphany, on top of the latest development release of WebKitGTK+, running on the GNOME master Flatpak runtime. The target audience is anyone who wants to assist with Epiphany development by testing the latest code and reporting bugs, so I’ve added the download link to Epiphany’s development page.

Since it uses Flatpak, there are no host dependencies asides from Flatpak itself, so it should work on any system that can run Flatpak. Thanks to the Flatpak sandbox, it’s far more secure than the version of Epiphany provided by your operating system. And of course, you enjoy automatic updates from GNOME Software or any software center that supports Flatpak.

Enjoy!

(P.S. If you want to use the latest stable version instead, with all the benefits provided by Flatpak, get that here.)

by Michael Catanzaro at January 24, 2018 10:58 PM



WebKitGTK+ Security Advisory WSA-2018-0002

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2018-4088
    • Versions affected: WebKitGTK+ before 2.18.6.
    • Credit to Jeonghoon Shin of Theori.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4089
    • Versions affected: WebKitGTK+ before 2.18.4.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4096
    • Versions affected: WebKitGTK+ before 2.18.6.
    • Credit to OSS-Fuzz.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7153
    • Versions affected: WebKitGTK+ before 2.18.6.
    • Credit to Jerry Decime.
    • Impact: Visiting a malicious website may lead to user interface spoofing. Description: Redirect responses to 401 Unauthorized may allow a malicious website to incorrectly display the lock icon on mixed content. This issue was addressed through improved URL display logic.
  • CVE-2017-7160
    • Versions affected: WebKitGTK+ before 2.18.6.
    • Credit to Richard Zhu (fluorescence) working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7161
    • Versions affected: WebKitGTK+ before 2.18.6.
    • Credit to Mitin Svyat.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A command injection issue existed in Web Inspector. This issue was addressed through improved escaping of special characters.
  • CVE-2017-7165
    • Versions affected: WebKitGTK+ before 2.18.6.
    • Credit to 360 Security working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13884
    • Versions affected: WebKitGTK+ before 2.18.6.
    • Credit to 360 Security working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13885
    • Versions affected: WebKitGTK+ before 2.18.6.
    • Credit to 360 Security working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

January 24, 2018 12:00 AM



WebKitGTK+ 2.18.6 released!

by The WebKitGTK+ Project

This is a bug fix release in the stable 2.18 series.

What’s new in the WebKitGTK+ 2.18.6 release?

Thanks to all the contributors who made possible this release.

January 24, 2018 12:00 AM



January 17, 2018

WebKitGTK+ 2.19.6 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.20 series.

What’s new in the WebKitGTK+ 2.19.6 release?

  • Fix crashes due to duplicated symbols in libjavascriptcoregtk and libwebkit2gtk.
  • Fix parsing of timeout values in WebDriver.
  • Implement get timeouts command in WebDriver.
  • Fix deadlock in GStreamer video sink during shutdown when accelerated compositing is disabled.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

January 17, 2018 12:00 AM



January 10, 2018

WebKitGTK+ Security Advisory WSA-2018-0001

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2017-5753
    • Versions affected: WebKitGTK+ before 2.18.5.
    • Credit to Jann Horn of Google Project Zero; and Paul Kocher in collaboration with Daniel Genkin of University of Pennsylvania and University of Maryland, Daniel Gruss of Graz University of Technology, Werner Haas of Cyberus Technology, Mike Hamburg of Rambus (Cryptography Research Division), Moritz Lipp of Graz University of Technology, Stefan Mangard of Graz University of Technology, Thomas Prescher of Cyberus Technology, Michael Schwarz of Graz University of Technology, and Yuval Yarom of University of Adelaide and Data61.
    • Impact: Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker via a side-channel analysis. This variant of the Spectre vulnerability triggers the speculative execution by performing a bounds-check bypass. Description: Security improvements are included to mitigate the effects.
  • CVE-2017-5715
    • Versions affected: WebKitGTK+ before 2.18.5.
    • Credit to Jann Horn of Google Project Zero; and Paul Kocher in collaboration with Daniel Genkin of University of Pennsylvania and University of Maryland, Daniel Gruss of Graz University of Technology, Werner Haas of Cyberus Technology, Mike Hamburg of Rambus (Cryptography Research Division), Moritz Lipp of Graz University of Technology, Stefan Mangard of Graz University of Technology, Thomas Prescher of Cyberus Technology, Michael Schwarz of Graz University of Technology, and Yuval Yarom of University of Adelaide and Data61.
    • Impact: Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker via a side-channel analysis. This variant of the Spectre vulnerability triggers the speculative execution by utilizing branch target injection. Description: Security improvements are included to mitigate the effects.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

January 10, 2018 12:00 AM



WebKitGTK+ 2.18.5 released!

by The WebKitGTK+ Project

This is a bug fix release in the stable 2.18 series.

What’s new in the WebKitGTK+ 2.18.5 release?

  • Disable SharedArrayBuffers from Web API.
  • Reduce the precision of “high” resolution time to 1ms.
  • Fix API documentation generation with newer gtk-doc.
  • Security fixes: includes improvements to mitigate the effects of Spectre (CVE-2017-5753 and CVE-2017-5715).

Thanks to all the contributors who made possible this release.

January 10, 2018 12:00 AM



January 09, 2018

WebKitGTK+ 2.19.5 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.20 series.

What’s new in the WebKitGTK+ 2.19.5 release?

  • This is a follow up release to export webkit_dom_dom_window_webkit_message_handlers_post_message() symbol that was hidden in 2.19.4 by mistake.

Thanks to all the contributors who made possible this release.

January 09, 2018 12:00 AM



WebKitGTK+ 2.19.4 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.20 series.

What’s new in the WebKitGTK+ 2.19.4 release?

  • Add web process API to detect when form is submitted via JavaScript.
  • Add new API to replace webkit_form_submission_request_get_text_fields() that is now deprecated.
  • Add WebKitWebView::web-process-terminated signal and deprecate web-process-crashed.
  • Fix rendering issues when editing text areas.
  • Use FastMalloc based GstAllocator for GStreamer.
  • Fix several crashes and rendering issues.
  • Translation updates: Swedish.

Thanks to all the contributors who made possible this release.

January 09, 2018 12:00 AM



December 19, 2017

WebKitGTK+ Security Advisory WSA-2017-0010

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2017-7156
    • Versions affected: WebKitGTK+ before 2.18.4.
    • Credit to an anonymous researcher.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7157
    • Versions affected: WebKitGTK+ before 2.18.1.
    • Credit to an anonymous researcher.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13856
    • Versions affected: WebKitGTK+ before 2.18.4.
    • Credit to Jeonghoon Shin.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13866
    • Versions affected: WebKitGTK+ before 2.18.4.
    • Credit to an anonymous researcher.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13870
    • Versions affected: WebKitGTK+ before 2.18.4.
    • Credit to an anonymous researcher.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

December 19, 2017 12:00 AM



WebKitGTK+ 2.18.4 released!

by The WebKitGTK+ Project

This is a bug fix release in the stable 2.18 series.

What’s new in the WebKitGTK+ 2.18.4 release?

  • Make WebDriver implementation more spec compliant.
  • Fix a bug when trying to remove cookies before a web process is spawned.
  • WebKitWebDriver process no longer links to libjavascriptcoregtk.
  • Fix several memory leaks in GStreamer media backend.
  • Security fixes: CVE-2017-13866, CVE-2017-13870, CVE-2017-7156, CVE-2017-13856.

Thanks to all the contributors who made possible this release.

December 19, 2017 12:00 AM



December 17, 2017

Epiphany Stable Flatpak Releases

by Michael Catanzaro

The latest stable version of Epiphany is now available on Flathub. Download it here. You should be able to double click the flatpakref to install it in GNOME Software, if you use any modern GNOME operating system not named Ubuntu. But, in my experience, GNOME Software is extremely buggy, and it often as not does not work for me. If you have trouble, you can use the command line:

flatpak install --from https://flathub.org/repo/appstream/org.gnome.Epiphany.flatpakref

This has actually been available for quite a while now, but I’ve delayed announcing it because some things needed to be fixed to work well under Flatpak. It’s good now.

I’ve also added a download link to Epiphany’s webpage, so that you can actually, you know, download and install the software. That’s a useful thing to be able to do!

Benefits

The obvious benefit of Flatpak is that you get the latest stable version of Epiphany (currently 3.26.5) and WebKitGTK+ (currently 2.18.3), no matter which version is shipped in your operating system.

The other major benefit of Flatpak is that the browser is protected by Flatpak’s top-class bubblewrap sandbox. This is, of course, a UI process sandbox, which is different from the sandboxing model used in other browsers, where individual browser tabs are sandboxed from each other. In theory, the bubblewrap sandbox should be harder to escape than the sandboxes used in other major browsers, because the attack surface is much smaller: other browsers are vulnerable to attack whenever IPC messages are sent between the web process and the UI process. Such vulnerabilities are mitigated by a UI process sandbox. The disadvantage of this approach is that tabs are not sandboxed from each other, as they would be with a web process sandbox, so it’s easier for a compromised tab to do bad things to your other tabs. I’m not sure which approach is better, but clearly either way is much better than having no sandbox at all. (I still hope to have a web process sandbox working for use when WebKit is used outside of Flatpak, but that’s not close to being ready yet.)

Problems

Now, there are a couple of loose ends. We do not yet have desktop notifications working under Flatpak, and we also don’t block the screen from turning off when you’re watching fullscreen video, so you’ll have to wiggle your mouse every five minutes or so when you’re watching YouTube to keep the lights on. These should not be too hard to fix; I’ll try to get them both working soon. Also, drag and drop does not work. I’m not nearly brave enough to try fixing that, though, so you’ll just have to live without drag and drop if you use the Flatpak version.

Also, unfortunately the stable GNOME runtimes do not receive regular updates. So while you get the latest version of Epiphany, most everything else will be older. This is not good. I try to make sure that WebKit gets updated, so you’ll have all the latest security updates there, but everything else is generally stuck at older versions. For example, the 3.26 runtime uses, for the most part, whatever software versions were current at the time of the 3.26.1 release, and any updates newer than that are just not included. That’s a shame, but the GNOME release team does not maintain GNOME’s Flatpak runtimes: we have three other other redundant places to store the same build information (JHBuild, GNOME Continuous, BuildStream) that we need to take care of, and adding yet another is not going to fly. Hopefully this situation will change soon, though, since we should be able to use BuildStream to replace the current JSON manifest that’s used to generate the Flatpak runtimes and keep everything up to date automatically. In the meantime, this is a problem to be aware of.

by Michael Catanzaro at December 17, 2017 07:21 PM



December 13, 2017

WebKitGTK+ 2.19.3 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.20 series.

What’s new in the WebKitGTK+ 2.19.3 release?

  • Fix web process crash at startup in bmalloc.
  • Fix several memory leaks in GStreamer media backend.
  • WebKitWebDriver process no longer links to libjavascriptcoregtk.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

December 13, 2017 12:00 AM



November 21, 2017

WebKitGTK+ 2.19.2 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.20 series.

What’s new in the WebKitGTK+ 2.19.2 release?

  • Add new API to add, retrieve and delete cookies via WebKitCookieManager.
  • Add functions to WebSettings to convert font sizes between points and pixels.
  • Ensure cookie operations take effect when they happen before a web process has been spawned.
  • Automatically adjust font size when GtkSettings:gtk-xft-dpi changes.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

November 21, 2017 12:00 AM



November 14, 2017

Igalia is Hiring

by Michael Catanzaro

Igalia is hiring web browser developers. If you think you’re a good candidate for one of these jobs, you’ll want to fill out the online application accompanying one of the postings. We’d love to hear from you.

We’re especially interested in hiring a browser graphics developer. We realize that not many graphics experts also have experience in web browser development, so it’s OK if you haven’t worked with web browsers before. Low-level Linux graphics experience is the more important qualification for this role.

Igalia is not just a great place to work on cool technical projects like WebKit. It’s also a political and social project: an egalitarian, worker-owned cooperative where everyone has an equal vote in company decisions and receives equal pay. It’s been around for 16 years, so it’s also not a startup. You can work remotely from wherever you happen to be, or from our office in A Coruña, Spain. You won’t have a boss, but you will be expected to work well with your colleagues. It’s not the right fit for everyone, but there’s nowhere I’d rather be.

by Michael Catanzaro at November 14, 2017 03:04 PM



November 10, 2017

WebKitGTK+ Security Advisory WSA-2017-0009

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2017-13783
    • Versions affected: WebKitGTK+ before 2.18.1.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13784
    • Versions affected: WebKitGTK+ before 2.18.1.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13785
    • Versions affected: WebKitGTK+ before 2.18.1.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13788
    • Versions affected: WebKitGTK+ before 2.18.3.
    • Credit to xisigr of Tencent’s Xuanwu Lab (tencent.com).
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13791
    • Versions affected: WebKitGTK+ before 2.18.1.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13792
    • Versions affected: WebKitGTK+ before 2.18.1.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13793
    • Versions affected: WebKitGTK+ before 2.18.1.
    • Credit to Hanul Choi working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13794
    • Versions affected: WebKitGTK+ before 2.18.1.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13795
    • Versions affected: WebKitGTK+ before 2.18.1.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13796
    • Versions affected: WebKitGTK+ before 2.18.1.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13798
    • Versions affected: WebKitGTK+ before 2.18.3.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13802
    • Versions affected: WebKitGTK+ before 2.18.1.
    • Credit to Ivan Fratric of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-13803
    • Versions affected: WebKitGTK+ before 2.18.3.
    • Credit to chenqin (陈钦) of Ant-financial Light-Year Security.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

November 10, 2017 12:00 AM



WebKitGTK+ 2.18.3 released!

by The WebKitGTK+ Project

This is a bug fix release in the stable 2.18 series.

What’s new in the WebKitGTK+ 2.18.3 release?

  • Improve calculation of font metrics to prevent scrollbars from being shown unnecessarily in some cases.
  • Fix handling of null capabilities in WebDriver implementation.
  • Security fixes: CVE-2017-13798, CVE-2017-13788, CVE-2017-13803.

Thanks to all the contributors who made possible this release.

November 10, 2017 12:00 AM



October 31, 2017

WebKitGTK+ 2.19.1 released!

by The WebKitGTK+ Project

This is the first development release leading toward 2.20 series.

What’s new in the WebKitGTK+ 2.19.1 release?

  • Add initial resource load statistics support.
  • Add API to expose availability of certain editing commands in WebKitEditorState.
  • Add API to query whether a WebKitNavigationAction is a redirect or not.
  • Improve complex text rendering.
  • Add support for the “system” CSS font family.
  • Implement low power mode.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

October 31, 2017 12:00 AM



October 27, 2017

WebKitGTK+ 2.18.2 released!

by The WebKitGTK+ Project

This is a bug fix release in the stable 2.18 series.

What’s new in the WebKitGTK+ 2.18.2 release?

  • Fix rendering of arabic text.
  • Fix a crash in the web process when decoding GIF images.
  • Fix rendering of wind in Windy.com.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

October 27, 2017 12:00 AM



October 21, 2017

Web Engines Hackfest, 2017 Edition

by Adrián Pérez de Castro

At the beginning of October I had the wonderful chance of attending the Web Engines Hackfest in A Coruña, hosted by Igalia. This year we were over 50 participants, which was great to associate even more faces to IRC nick names, but more importantly allows hackers working at all the levels of the Web stack to share a common space for a few days, making it possible to discuss complex topics and figure out the future of the projects which allow humanity to see pictures of cute kittens — among many other things.

Mandatory fluff (CC-BY-NC).

During the hackfest I worked mostly on three things:

  • Preparing the code of the WPE WebKit port to start making preview releases.

  • A patch set which adds WPE packages to Buildroot.

  • Enabling support for the CSS generic system font family.

Fun trivia: Most of the WebKit contributors work from the United States, so the week of the Web Engines hackfest is probably the only single moment during the whole year that there is a sizeable peak of activity in European day times.

Watching repository activity during the hackfest.

Towards WPE Releases

At Igalia we are making an important investment in the WPE WebKit port, which is specially targeted towards embedded devices. An important milestone for the project was reached last May when the code was moved to main WebKit repository, and has been receiving the usual stream of improvements and bug fixes. We are now approaching the moment where we feel that is is ready to start making releases, which is another major milestone.

Our plan for the WPE is to synchronize with WebKitGTK+, and produce releases for both in parallel. This is important because both ports share a good amount of their code and base dependencies (GStreamer, GLib, libsoup) and our efforts to stabilize the GTK+ port before each release will benefit the WPE one as well, and vice versa. In the coming weeks we will be publishing the first official tarball starting off the WebKitGTK+ 2.18.x stable branch.

Wild WEBKIT PORT appeared!

Syncing the releases for both ports means that:

  • Both stable and unstable releases are done in sync with the GNOME release schedule. Unstable releases start at version X.Y.1, with Y being an odd number.

  • About one month before the release dates, we create a new release branch and from there on we work on stabilizing the code. At least one testing release with with version X.Y.90 will be made. This is also what GNOME does, and we will mimic this to avoid confusion for downstream packagers.

  • The stable release will have version X.Y+1.0. Further maintenance releases happen from the release branch as needed. At the same time, a new cycle of unstable releases is started based on the code from the tip of the repository.

Believe it or not, preparing a codebase for its first releases involves quite a lot of work, and this is what took most of my coding time during the Web Engines Hackfest and also the following weeks: from small fixes for build failures all the way to making sure that public API headers (only the correct ones!) are installed and usable, that applications can be properly linked, and that release tarballs can actually be created. Exhausting? Well, do not forget that we need to set up a web server to host the tarballs, a small website, and the documentation. The latter has to be generated (there is still pending work in this regard), and the whole process of making a release scripted.

Still with me? Great. Now for a plot twist: we won't be making proper releases just yet.

APIs, ABIs, and Releases

There is one topic which I did not touch yet: API/ABI stability. Having done a release implies that the public API and ABI which are part of it are stable, and they are not subject to change.

Right after upstreaming WPE we switched over from the cross-port WebKit2 C API and added a new, GLib-based API to WPE. It is remarkably similar (if not the same in many cases) to the API exposed by WebKitGTK+, and this makes us confident that the new API is higher-level, more ergonomic, and better overall. At the same time, we would like third party developers to give it a try (which is easier having releases) while retaining the possibility of getting feedback and improving the WPE GLib API before setting it on stone (which is not possible after a release).

It is for this reason that at least during the first WPE release cycle we will make preview releases, meaning that there might be API and ABI changes from one release to the next. As usual we will not be making breaking changes in between releases of the same stable series, i.e. code written for 2.18.0 will continue to build unchanged with any subsequent 2.18.X release.

At any rate, we do not expect the API to receive big changes because —as explained above— it mimics the one for WebKitGTK+, which has already proven itself both powerful enough for complex applications and convenient to use for the simpler ones. Due to this, I encourage developers to try out WPE as soon as we have the first preview release fresh out of the oven.

Packaging for Buildroot

At Igalia we routinely work with embedded devices, and often we make use of Buildroot for cross-compilation. Having actual releases of WPE will allow us to contribute a set of build definitions for the WPE WebKit port and its dependencies — something that I have already started working on.

Lately I have been taking care of keeping the WebKitGTK+ packaging for Buildroot up-to-date and it has been delightful to work with such a welcoming community. I am looking forward to having WPE supported there, and to keep maintaining the build definitions for both. This will allow making use of WPE with relative ease, while ensuring that Buildroot users will pick our updates promptly.

Generic System Font

Some applications like GNOME Web Epiphany use a WebKitWebView to display widget-like controls which try to follow the design of the rest of the desktop. Unfortunately for GNOME applications this means Cantarell gets hardcoded in the style sheet —it is the default font after all— and this results in mismatched fonts when the user has chosen a different font for the interface (e.g. in Tweaks). You can see this in the following screen capture of Epiphany:

Web using hardcoded Cantarell and (on hover) -webkit-system-font.

Here I have configured the beautiful Inter UI font as the default for the desktop user interface. Now, if you roll your mouse over the image, you will see how much better it looks to use a consistent font. This change also affects the list of plugins and applications, error messages, and in general all the about: pages.

If you are running GNOME 3.26, this is already fixed using font: menu (part of the CSS spec since ye olde CSS 2.1) — but we can do better: Safari has had support since 2015, for a generic “system” font family, similar to sans-serif or cursive:

/* Using the new generic font family (nice!). */
body {
    font-family: -webkit-system-font;
}

/* Using CSS 2.1 font shorthands (not so nice). */
body {
    font: menu;       /* Pick ALL font attributes... */
    font-size: 12pt;  /* ...then reset some of them. */
    font-weight: 400;
}

During the hackfest I implemented the needed moving parts in WebKitGTK+ by querying the GtkSettings::gtk-font-name property. This can be used in HTML content shown in Epiphany as part of the UI, and to make the Web Inspector use the system font as well.

Web Inspector using Cantarell, the default GNOME 3 font (full size).

I am convinced that users do notice and appreciate attention to detail, even if they do unconsciously, and therefore it is worthwhile to work on this kind of improvements. Plus, as a design enthusiast with a slight case of typographic OCD, I cannot stop myself from noticing inconsistent usage of fonts and my mind is now at ease knowing that opening the Web Inspector won't be such a jarring experience anymore.

Outro

But there's one more thing: On occasion we developers have to debug situations in which a process is seemingly stuck. One useful technique involves running the offending process under the control of a debugger (or, in an embedded device, under gdbserver and controlled remotely), interrupting its execution at intervals, and printing stack traces to try and figure out what is going on. Unfortunately, in some circumstances running a debugger can be difficult or impractical. Wouldn't it be grand if it was possible to interrupt the process without needing a debugger and request a stack trace? Enter “Out-Of-Band Stack Traces” (proof of concept):

  1. The process installs a signal handler using sigaction(7), with the SA_SIGINFO flag set.

  2. On reception of the signal, the kernel interrupts the process (even if it's in an infinite loop), and invokes the signal handler passing an extra pointer to an ucontext_t value, which contains a snapshot of the execution status of the thread which was in the CPU before the signal handler was invoked. This is true for many platform including Linux and most BSDs.

  3. The signal handler code can get obtain the instruction and stack pointers from the ucontext_t value, and walk the stack to produce a stack trace of the code that was being executed. Jackpot! This is of course architecture dependent but not difficult to get right (and well tested) for the most common ones like x86 and ARM.

The nice thing about this approach is that the code that obtains the stack trace is built into the program (no rebuilds needed), and it does not even require to relaunch the process in a debugger — which can be crucial for analyzing situations which are hard to reproduce, or which do not happen when running inside a debugger. I am looking forward to have some time to integrate this properly into WebKitGTK+ and specially WPE, because it will be most useful in embedded devices.

by aperez (adrian@perezdecastro.org) at October 21, 2017 12:30 AM



October 18, 2017

WebKitGTK+ Security Advisory WSA-2017-0008

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2017-7081
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A memory corruption issue was addressed through improved input validation.
  • CVE-2017-7087
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7089
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to Anton Lopanitsyn of ONSEC, Frans Rosén of Detectify.
    • Impact: Processing maliciously crafted web content may lead to universal cross site scripting. Description: A logic issue existed in the handling of the parent-tab. This issue was addressed with improved state management.
  • CVE-2017-7090
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to Apple.
    • Impact: Cookies belonging to one origin may be sent to another origin. Description: A permissions issue existed in the handling of web browser cookies. This issue was addressed by no longer returning cookies for custom URL schemes.
  • CVE-2017-7091
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to Wei Yuan of Baidu Security Lab working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7092
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to Qixun Zhao (@S0rryMybad) of Qihoo 360 Vulcan Team, Samuel Gro and Niklas Baumstark working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7093
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to Samuel Gro and Niklas Baumstark working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7094
    • Versions affected: WebKitGTK+ before 2.16.3.
    • Credit to Tim Michaud (@TimGMichaud) of Leviathan Security Group.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7095
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to Wang Junjie, Wei Lei, and Liu Yang of Nanyang Technological University working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7096
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to Wei Yuan of Baidu Security Lab.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7098
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to Felipe Freitas of Instituto Tecnológico de Aeronáutica.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7099
    • Versions affected: WebKitGTK+ before 2.16.4.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7100
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to Masato Kinugawa and Mario Heiderich of Cure53.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7102
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to Wang Junjie, Wei Lei, and Liu Yang of Nanyang Technological University.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7104
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to likemeng of Baidu Secutity Lab.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7107
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to Wang Junjie, Wei Lei, and Liu Yang of Nanyang Technological University.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7109
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to avlidienbrunn.
    • Impact: Processing maliciously crafted web content may lead to a cross site scripting attack. Description: Application Cache policy may be unexpectedly applied.
  • CVE-2017-7111
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to likemeng of Baidu Security Lab (xlab.baidu.com) working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7117
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7120
    • Versions affected: WebKitGTK+ before 2.18.0.
    • Credit to chenqin (陈钦) of Ant-financial Light-Year Security Lab.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-7142
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to an anonymous researcher.
    • Impact: Website data may persist after a Safari Private browsing session. Description: An information leakage issue existed in the handling of website data in Safari Private windows. This issue was addressed with improved data handling.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

October 18, 2017 12:00 AM



WebKitGTK+ 2.18.1 released!

by The WebKitGTK+ Project

This is the first bug fix release in the stable 2.18 series.

What’s new in the WebKitGTK+ 2.18.1 release?

  • Improve performance of GIF animations.
  • Fix garbled display in GMail.
  • Fix rendering of several material design icons when using the web font.
  • Fix flickering when resizing the window in Wayland.
  • Prevent default kerberos authentication credentials from being used in ephemeral sessions.
  • Fix a crash when webkit_web_resource_get_data() is cancelled.
  • Correctly handle touchmove and touchend events in WebKitWebView.
  • Fix the build with enchant 2.1.1.
  • Fix the build in HPPA and Alpha.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

October 18, 2017 12:00 AM



October 16, 2017

Who knew we still had low-hanging fruits?

by Gustavo Noronha

Earlier this month I had the pleasure of attending the Web Engines Hackfest, hosted by Igalia at their offices in A Coruña, and also sponsored by my employer, Collabora, Google and Mozilla. It has grown a lot and we had many new people this year.

Fun fact: I am one of the 3 or 4 people who have attended all of the editions of the hackfest since its inception in 2009, when it was called WebKitGTK+ hackfest \o/

20171002_204405

It was a great get together where I met many friends and made some new ones. Had plenty of discussions, mainly with Antonio Gomes and Google’s Robert Kroeger, about the way forward for Chromium on Wayland.

We had the opportunity of explaining how we at Collabora cooperated with igalians to implemented and optimise a Wayland nested compositor for WebKit2 to share buffers between processes in an efficient way even on broken drivers. Most of the discussions and some of the work that led to this was done in previous hackfests, by the way!

20171002_193518

The idea seems to have been mostly welcomed, the only concern being that Wayland’s interfaces would need to be tested for security (fuzzed). So we may end up going that same route with Chromium for allowing process separation between the UI and GPU (being renamed Viz, currently) processes.

On another note, and going back to the title of the post, at Collabora we have recently adopted Mattermost to replace our internal IRC server. Many Collaborans have decided to use Mattermost through an Epiphany Web Application or through a simple Python application that just shows a GTK+ window wrapping a WebKitGTK+ WebView.

20171002_101952

Some people noticed that when the connection was lost Mattermost would take a very long time to notice and reconnect – its web sockets were taking a long, long time to timeout, according to our colleague Andrew Shadura.

I did some quick searching on the codebase and noticed WebCore has a NetworkStateNotifier interface that it uses to get notified when connection changes. That was not implemented for WebKitGTK+, so it was likely what caused stuff to linger when a connection hiccup happened. Given we have GNetworkMonitor, implementation of the missing interfaces required only 3 lines of actual code (plus the necessary boilerplate)!

screenshot-from-2017-10-16-11-13-39

I was surprised to still find such as low hanging fruit in WebKitGTK+, so I decided to look for more. Turns out WebCore also has a notifier for low power situations, which was implemented only by the iOS port, and causes the engine to throttle some timers and avoid some expensive checks it would do in normal situations. This required a few more lines to implement using upower-glib, but not that many either!

That was the fun I had during the hackfest in terms of coding. Mostly I had fun just lurking in break out sessions discussing the past, present and future of tech such as WebRTC, Servo, Rust, WebKit, Chromium, WebVR, and more. I also beat a few challengers in Street Fighter 2, as usual.

I’d like to say thanks to Collabora, Igalia, Google, and Mozilla for sponsoring and attending the hackfest. Thanks to Igalia for hosting and to Collabora for sponsoring my attendance along with two other Collaborans. It was a great hackfest and I’m looking forward to the next one! See you in 2018 =)

by kov at October 16, 2017 06:23 PM



September 11, 2017

WebKitGTK+ 2.18.0 released!

by The WebKitGTK+ Project

This is the first stable release in the 2.18 series.

Highlights of the WebKitGTK+ 2.18.0 release

  • Initial WebDriver support.
  • New remote inspector infrastructure.
  • WebCrypto API support is now enabled by default.
  • GStreamerGL is enabled by default when building with GStreamer >= 1.10.
  • Kinetic scrolling support.
  • New API to create a WebKitContextMenuItem from a GAction.
  • New API to allow overriding the popup menu of select elements.

For more details about all the changes included in WebKitGTK+ 2.18 see the NEWS file that is included in the tarball.

Thanks to all the contributors who made possible this release.

September 11, 2017 12:00 AM



September 09, 2017

WebDriver support in WebKitGTK+ 2.18

by Carlos García Campos

WebDriver is an automation API to control a web browser. It allows to create automated tests for web applications independently of the browser and platform. WebKitGTK+ 2.18, that will be released next week, includes an initial implementation of the WebDriver specification.

WebDriver in WebKitGTK+

There’s a new process (WebKitWebDriver) that works as the server, processing the clients requests to spawn and control the web browser. The WebKitGTK+ driver is not tied to any specific browser, it can be used with any WebKitGTK+ based browser, but it uses MiniBrowser as the default. The driver uses the same remote controlling protocol used by the remote inspector to communicate and control the web browser instance. The implementation is not complete yet, but it’s enough for what many users need.

The clients

The web application tests are the clients of the WebDriver server. The Selenium project provides APIs for different languages (Java, Python, Ruby, etc.) to write the tests. Python is the only language supported by WebKitGTK+ for now. It’s not yet upstream, but we hope it will be integrated soon. In the meantime you can use our fork in github. Let’s see an example to understand how it works and what we can do.

from selenium import webdriver

# Create a WebKitGTK driver instance. It spawns WebKitWebDriver 
# process automatically that will launch MiniBrowser.
wkgtk = webdriver.WebKitGTK()

# Let's load the WebKitGTK+ website.
wkgtk.get("https://www.webkitgtk.org")

# Find the GNOME link.
gnome = wkgtk.find_element_by_partial_link_text("GNOME")

# Click on the link. 
gnome.click()

# Find the search form. 
search = wkgtk.find_element_by_id("searchform")

# Find the first input element in the search form.
text_field = search.find_element_by_tag_name("input")

# Type epiphany in the search field and submit.
text_field.send_keys("epiphany")
text_field.submit()

# Let's count the links in the contents div to check we got results.
contents = wkgtk.find_element_by_class_name("content")
links = contents.find_elements_by_tag_name("a")
assert len(links) > 0

# Quit the driver. The session is closed so MiniBrowser 
# will be closed and then WebKitWebDriver process finishes.
wkgtk.quit()

Note that this is just an example to show how to write a test and what kind of things you can do, there are better ways to achieve the same results, and it depends on the current source of public websites, so it might not work in the future.

Web browsers / applications

As I said before, WebKitWebDriver process supports any WebKitGTK+ based browser, but that doesn’t mean all browsers can automatically be controlled by automation (that would be scary). WebKitGTK+ 2.18 also provides new API for applications to support automation.

  • First of all the application has to explicitly enable automation using webkit_web_context_set_automation_allowed(). It’s important to know that the WebKitGTK+ API doesn’t allow to enable automation in several WebKitWebContexts at the same time. The driver will spawn the application when a new session is requested, so the application should enable automation at startup. It’s recommended that applications add a new command line option to enable automation, and only enable it when provided.
  • After launching the application the driver will request the browser to create a new automation session. The signal “automation-started” will be emitted in the context to notify the application that a new session has been created. If automation is not allowed in the context, the session won’t be created and the signal won’t be emitted either.
  • A WebKitAutomationSession object is passed as parameter to the “automation-started” signal. This can be used to provide information about the application (name and version) to the driver that will match them with what the client requires accepting or rejecting the session request.
  • The WebKitAutomationSession will emit the signal “create-web-view” every time the driver needs to create a new web view. The application can then create a new window or tab containing the new web view that should be returned by the signal. This signal will always be emitted even if the browser has already an initial web view open, in that case it’s recommened to return the existing empty web view.
  • Web views are also automation aware, similar to ephemeral web views, web views that allow automation should be created with the constructor property “is-controlled-by-automation” enabled.

This is the new API that applications need to implement to support WebDriver, it’s designed to be as safe as possible, but there are many things that can’t be controlled by WebKitGTK+, so we have several recommendations for applications that want to support automation:

  • Add a way to enable automation in your application at startup, like a command line option, that is disabled by default. Never allow automation in a normal application instance.
  • Enabling automation is not the only thing the application should do, so add an automation mode to your application.
  • Add visual feedback when in automation mode, like changing the theme, the window title or whatever that makes clear that a window or instance of the application is controllable by automation.
  • Add a message to explain that the window is being controlled by automation and the user is not expected to use it.
  • Use ephemeral web views in automation mode.
  • Use a temporal user profile in application mode, do not allow automation to change the history, bookmarks, etc. of an existing user.
  • Do not load any homepage in automation mode, just keep an empty web view (about:blank) that can be used when a new web view is requested by automation.

The WebKitGTK client driver

Applications need to implement the new automation API to support WebDriver, but the WebKitWebDriver process doesn’t know how to launch the browsers. That information should be provided by the client using the WebKitGTKOptions object. The driver constructor can receive an instance of a WebKitGTKOptions object, with the browser information and other options. Let’s see how it works with an example to launch epiphany:

from selenium import webdriver
from selenium.webdriver import WebKitGTKOptions

options = WebKitGTKOptions()
options.browser_executable_path = "/usr/bin/epiphany"
options.add_browser_argument("--automation-mode")
epiphany = webdriver.WebKitGTK(browser_options=options)

Again, this is just an example, Epiphany doesn’t even support WebDriver yet. Browsers or applications could create their own drivers on top of the WebKitGTK one to make it more convenient to use.

from selenium import webdriver
epiphany = webdriver.Epiphany()

Plans

During the next release cycle, we plan to do the following tasks:

  • Complete the implementation: add support for all commands in the spec and complete the ones that are partially supported now.
  • Add support for running the WPT WebDriver tests in the WebKit bots.
  • Add a WebKitGTK driver implementation for other languages in Selenium.
  • Add support for automation in Epiphany.
  • Add WebDriver support to WPE/dyz.

by carlos garcia campos at September 09, 2017 05:33 PM



September 04, 2017

WebKitGTK+ 2.17.92 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.18 series.

What’s new in the WebKitGTK+ 2.17.92 release?

  • Improve CPU usage when rendering under Wayland in accelerated compositing mode.
  • Improve the memory consumption of the UI process under Wayland.
  • Fix rendering issues in some web sites with accelerated compositing enabled.
  • Fix a web process crash when closing the WebView.
  • Initialize libgcrypt in the network process too.
  • Show controls if a video element isn’t allowed to play inline.
  • Add support for cookies and screenshots commands in WebDriver.
  • Fix several crashes and rendering issues.
  • Translation updates: Brazilian Portuguese, Polish.

Thanks to all the contributors who made possible this release.

September 04, 2017 12:00 AM



August 31, 2017

Some rough numbers on WebKit code

by Xabier Rodríguez Calvar

My wife asked me for some rough LOC numbers on the WebKit project and I think I could share them with you here as well. They come from r221232. As I’ll take into account some generated code it is relevant to mention that I built WebKitGTK+ with the default CMake options.

First thing I did was running sloccount Source and got the following numbers:

cpp: 2526061 (70.57%)
ansic: 396906 (11.09%)
asm: 207284 (5.79%)
javascript: 175059 (4.89%)
java: 74458 (2.08%)
perl: 73331 (2.05%)
objc: 44422 (1.24%)
python: 38862 (1.09%)
cs: 13011 (0.36%)
ruby: 11605 (0.32%)
xml: 11396 (0.32%)
sh: 3747 (0.10%)
yacc: 2167 (0.06%)
lex: 1007 (0.03%)
lisp: 89 (0.00%)
php: 10 (0.00%)

This number do not include IDL code so I did some grepping to get the number myself that gave me 19632 IDL lines:

$ find Source/ -name ".idl" | xargs cat | grep -ve "^[[:space:]]\/*" -ve "^[[:space:]]*" -ve "^[[:space:]]$" -ve "^[[:space:]][$" -ve "^[[:space:]]};$" | wc -l
19632

The interesting part of the IDL files is that they are used to generate code so those 19632 IDL lines expand to:

ansic: 699140 (65.25%)
cpp: 368720 (34.41%)
python: 1492 (0.14%)
xml: 1040 (0.10%)
javascript: 883 (0.08%)
asm: 169 (0.02%)
perl: 11 (0.00%)

Let’s have a look now at the LayoutTests (they test the functionality of WebCore + the platform). Tests are composed mainly by HTML files so if you run sloccount LayoutTests you get:

javascript: 401159 (76.74%)
python: 87231 (16.69%)
xml: 22978 (4.40%)
php: 4784 (0.92%)
ansic: 3661 (0.70%)
perl: 2726 (0.52%)
sh: 199 (0.04%)

It’s quite interesting to see that sloccount does not consider HTML which is quite relevant when you’re testing a web engine so again, we have to count them manually (thanks to Carlos López who helped me to properly grep here as some binary lines were giving me a headache to get the numbers):

find LayoutTests/ -name ".html" -print0 | xargs -0 cat | strings | grep -Pv "^[[:space:]]$" | wc -l
2205690

You can see 2205690 of “meaningful lines” that combine HTML + other languages that you can see above. I can’t substract here to just get the HTML lines because the number above take into account files with a different extension than HTML, though many of them do include other languages, specially JavaScript.

But the LayoutTests do not include only pure WebKit tests. There are some imported ones so it might be interesting to run the same procedure under LayoutTests/imported to see which ones are imported and not written directly into the WebKit project. I emphasize that because they can be written by WebKit developers in other repositories and actually I can present myself and Youenn Fablet as an example as we wrote tests some tests that were finally moved into the specification and included back later when imported. So again, sloccount LayoutTests/imported:

python: 84803 (59.99%)
javascript: 51794 (36.64%)
ansic: 3661 (2.59%)
php: 575 (0.41%)
xml: 250 (0.18%)
sh: 199 (0.14%)
perl: 86 (0.06%)

The same procedure to count HTML + other stuff lines inside that directory gives a number of 295490:

$ find LayoutTests/imported/ -name ".html" -print0 | xargs -0 cat | strings | grep -Pv "^[[:space:]]$" | wc -l
295490

There are also some other tests that we can talk about, for example the JSTests. I’ll mention already the numbers summed up regarding languages and the manual HTML code (if you made it here, you know the drill already):

javascript: 1713200 (98.64%)
xml: 20665 (1.19%)
perl: 2449 (0.14%)
python: 421 (0.02%)
ruby: 56 (0.00%)
sh: 38 (0.00%)
HTML+stuff: 997

ManualTests:

javascript: 297 (41.02%)
ansic: 187 (25.83%)
java: 118 (16.30%)
xml: 103 (14.23%)
php: 10 (1.38%)
perl: 9 (1.24%)
HTML+stuff: 16026

PerformanceTests:

javascript: 950916 (83.12%)
cpp: 147194 (12.87%)
ansic: 38540 (3.37%)
asm: 5466 (0.48%)
sh: 872 (0.08%)
ruby: 419 (0.04%)
perl: 348 (0.03%)
python: 325 (0.03%)
xml: 5 (0.00%)
HTML+stuff: 238002

TestsWebKitAPI:

cpp: 44753 (99.45%)
ansic: 163 (0.36%)
objc: 76 (0.17%)
xml: 7 (0.02%)
javascript: 1 (0.00%)
HTML+stuff: 3887

And this is all. Remember that these are just some rough statistics, not a “scientific” paper.

Update:

In her expert opinion, in the WebKit project we are devoting around 50% of the total LOC to testing, which makes it a software engineering “textbook” project regarding testing and I think we can be proud of it!

by calvaris at August 31, 2017 09:03 AM



August 25, 2017

WebKitGTK+ Security Advisory WSA-2017-0007

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2017-1000121
    • Versions affected: WebKitGTK+ before 2.16.3.
    • Credit to Nathan Crandall.
    • Impact: Processing maliciously crafted input may lead to arbitrary code execution or application crash. Description: An input validation issue on the handling of UNIX IPC messages may allow an attacker to trigger an integer overflow. The issue was addressed through improved state management.
  • CVE-2017-1000122
    • Versions affected: WebKitGTK+ before 2.16.3.
    • Credit to Nathan Crandall.
    • Impact: Processing maliciously crafted input may lead to application crash. Description: An input validation issue on the handling of UNIX IPC messages allows an attacker to trigger an application crash. The issue was addressed through improved state management.

We recommend updating to the last stable version of WebKitGTK+. It is the best way of ensuring that you are running a safe version of WebKitGTK+. Please check our website for information about the last stable releases.

Further information about WebKitGTK+ Security Advisories can be found at: https://webkitgtk.org/security.html

August 25, 2017 12:00 AM



August 18, 2017

WebKitGTK+ 2.17.91 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.18 series.

What’s new in the WebKitGTK+ 2.17.91 release?

  • Fix proxy HTTP authentication for HTTPS requests.
  • Stop kinetic scrolling when a zero movement is reached.
  • Fix UI process crash when selecting text.
  • Fix UI process crash when loading a favicon.
  • Properly handle WebDriver click command on option elements.
  • Fix web process crash when resizing the window with accelerated compositing enabled.
  • Fix crashes in 32 bit systems due to incorrect use of GVariant.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

August 18, 2017 12:00 AM



August 09, 2017

On Firefox Sync

by Michael Catanzaro

Epiphany 3.26 is, unfortunately, not going to be packed with cool new features like 3.24 was. We’ve just been too busy working on improving WebKit this cycle. But there is one cool new thing: Firefox Sync support. You can sync bookmarks, history, passwords, and open tabs with other Epiphany instances and as well as both desktop and mobile Firefox. This is already enabled in 3.25.90. Just go to the Sync tab in Preferences and sign in or create your Firefox account there. Please test it out and report bugs now, so we can quash problems you find before 3.26.0 rather than after.

Some thank yous are in order:

  • Thanks to Gabriel Ivascu, for writing all the code.
  • Thanks to Google and Igalia for sponsoring Gabriel’s work.
  • Thanks to Mozilla. This project would never have been possible if Mozilla had not carefully written its terms of service to allow such use.

Go forth and sync!

by Michael Catanzaro at August 09, 2017 07:57 PM



WebKitGTK+ 2.17.90 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.18 series.

What’s new in the WebKitGTK+ 2.17.90 release?

  • WebCrypto API support is now enabled by default.
  • Add API to provide browser information required by automation.
  • Fix the expiration date of manually added cookies.
  • Add support for alerts in WebDriver.
  • WebKitDatabaseProcess binary has been renamed to WebKitStorageProcess.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

August 09, 2017 12:00 AM



August 06, 2017

Endgame for WebKit Woes

by Michael Catanzaro

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!

by Michael Catanzaro at August 06, 2017 09:47 PM



July 26, 2017

WebKitGTK+ 2.17.5 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.18 series.

What’s new in the WebKitGTK+ 2.17.5 release?

  • Add initial implementation of WebDriver.
  • Enable GStreamerGL by default when building with GStreamer >= 1.10.
  • Fix position of context menu in Wayland.
  • Properly close cookies database at network process exit.
  • Fix several crashes and rendering issues.
  • Translation updates: Ukrainian.

Thanks to all the contributors who made possible this release.

July 26, 2017 12:00 AM