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



July 25, 2017

WebKitGTK+ Security Advisory WSA-2017-0006

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2017-7006
    • Versions affected: WebKitGTK+ before 2.16.2.
    • Credit to David Kohlbrenner of UC San Diego, an anonymous researcher.
    • Impact: A malicious website may exfiltrate data cross-origin. Description: Processing maliciously crafted web content may allow cross-origin data to be exfiltrated by using SVG filters to conduct a timing side-channel attack. This issue was addressed by not painting the cross-origin buffer into the frame that gets filtered.
  • CVE-2017-7011
    • Versions affected: WebKitGTK+ before 2.16.3.
    • Credit to xisigr of Tencent’s Xuanwu Lab (tencent.com).
    • Impact: Visiting a malicious website may lead to address bar spoofing. Description: A state management issue was addressed with improved frame handling.
  • CVE-2017-7012
    • Versions affected: WebKitGTK+ before 2.16.2.
    • 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-7018
    • Versions affected: WebKitGTK+ before 2.16.6.
    • 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-7019
    • Versions affected: WebKitGTK+ before 2.16.2.
    • Credit to Zhiyang Zeng of Tencent Security Platform Department.
    • 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-7020
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to likemeng 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-7030
    • Versions affected: WebKitGTK+ before 2.16.6.
    • 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-7034
    • Versions affected: WebKitGTK+ before 2.16.6.
    • 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-7037
    • Versions affected: WebKitGTK+ before 2.16.6.
    • 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-7038
    • Versions affected: WebKitGTK+ before 2.16.2.
    • Credit to Neil Jenkins of FastMail Pty Ltd, Egor Karbutov (@ShikariSenpai) of Digital Security and Egor Saltykov (@ansjdnakjdnajkd) of Digital Security.
    • Impact: Processing maliciously crafted web content with DOMParser may lead to cross site scripting. Description: A logic issue existed in the handling of DOMParser. This issue was addressed with improved state management.
  • CVE-2017-7039
    • Versions affected: WebKitGTK+ before 2.16.6.
    • 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-7040
    • Versions affected: WebKitGTK+ before 2.16.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-7041
    • Versions affected: WebKitGTK+ before 2.16.2.
    • 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-7042
    • Versions affected: WebKitGTK+ before 2.16.2.
    • 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-7043
    • Versions affected: WebKitGTK+ before 2.16.2.
    • 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-7046
    • Versions affected: WebKitGTK+ before 2.16.6.
    • 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-7048
    • Versions affected: WebKitGTK+ before 2.16.6.
    • 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-7049
    • Versions affected: WebKitGTK+ before 2.16.2.
    • 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 through improved memory handling.
  • CVE-2017-7052
    • Versions affected: WebKitGTK+ before 2.16.4.
    • Credit to cc 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-7055
    • Versions affected: WebKitGTK+ before 2.16.6.
    • Credit to The UK’s National Cyber Security Centre (NCSC).
    • 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-7056
    • Versions affected: WebKitGTK+ before 2.16.6.
    • 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-7059
    • Versions affected: WebKitGTK+ before 2.16.3.
    • Credit to an anonymous researcher.
    • Impact: Processing maliciously crafted web content with DOMParser may lead to cross site scripting. Description: A logic issue existed in the handling of DOMParser. This issue was addressed with improved state management.
  • CVE-2017-7061
    • Versions affected: WebKitGTK+ before 2.16.6.
    • 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-7064
    • Versions affected: WebKitGTK+ before 2.16.6.
    • Credit to lokihardt of Google Project Zero.
    • Impact: An application may be able to read restricted memory. Description: A memory initialization issue was addressed through 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

July 25, 2017 12:00 AM



July 24, 2017

WebKitGTK+ 2.16.6 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.16.6 release?

Thanks to all the contributors who made possible this release.

July 24, 2017 12:00 AM



June 27, 2017

WebKitGTK+ 2.16.5 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.16.5 release?

  • Fix a web process crash when page finishes loading in several web sites.
  • Fix the menu of select elements not showing in some cases under Wayland.

Thanks to all the contributors who made possible this release.

June 27, 2017 12:00 AM



June 21, 2017

WebKitGTK+ Security Advisory WSA-2017-0005

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2017-2538
    • Versions affected: WebKitGTK+ before 2.16.4.
    • 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-2424
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Paul Thomson (using the GLFuzz tool) of the Multicore Programming Group, Imperial College London.
    • Impact: Processing maliciously crafted web content may result in the disclosure of process memory. Description: An information disclosure issue existed in the processing of OpenGL shaders. This issue was addressed through improved memory 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

June 21, 2017 12:00 AM



June 20, 2017

WebKitGTK+ 2.16.4 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.16.4 release?

  • Fix web process deadlock when seeking youtube videos.
  • Fix blob downloads.
  • Improve theme rendering performance when using GTK+ >= 3.20.
  • Fix positioning of popup menus in Wayland.
  • Fix several crashes and rendering issues.
  • Security fixes: CVE-2017-2538.

Thanks to all the contributors who made possible this release.

June 20, 2017 12:00 AM



June 19, 2017

WebKitGTK+ 2.17.4 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.18 series.

What’s new in the WebKitGTK+ 2.17.4 release?

  • Add API to allow overriding popup menus.
  • Add kinetic scrolling support.
  • Improve theme rendering performance when using GTK+ >= 3.20.
  • Improve error message when webkit_web_view_run_javascript() fails due to a JavaScript exception.
  • Fix artifacts when rendering large images.
  • Fix blob downloads.
  • Fix web process deadlock when seeking youtube videos.
  • Fix alpha premultiplying when using cairo to draw the video frames.
  • Fix web process deadlock when closing the remote inspector frontend.
  • Update several web inspector icons.
  • Fix several crashes and rendering issues.
  • Translation updates: Spanish.

Thanks to all the contributors who made possible this release.

June 19, 2017 12:00 AM



June 15, 2017

Debian Stretch ships latest WebKitGTK+

by Michael Catanzaro

I’ll keep this update short. Debian has decided to ship the latest version of WebKitGTK+, 2.16.3, in its upcoming Stretch release. Since Debian was the last major distribution holding out on providing WebKit security updates, this is a big deal. Huge thanks to Jeremy Bicha for making this possible.

The bad news is that Debian is still considering whether or not to provide periodic security updates after the release, so there might not be any. But maybe there will be. We will have to wait and see. At least releasing with the latest version is a big step in the right direction.

by Michael Catanzaro at June 15, 2017 04:34 PM



May 25, 2017

WebKitGTK+ Security Advisory WSA-2017-0004

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2017-2496
    • Versions affected: WebKitGTK+ before 2.16.3.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2504
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to universal cross site scripting (UXSS). Description: A logic issue existed in the handling of WebKit Editor commands. This issue was addressed with improved state management.
  • CVE-2017-2505
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2506
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to Zheng Huang of the Baidu Security Lab working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2508
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to universal cross site scripting (UXSS). Description: A logic issue existed in the handling of WebKit container nodes. This issue was addressed with improved state management.
  • CVE-2017-2510
    • Versions affected: WebKitGTK+ before 2.16.3.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to universal cross site scripting (UXSS). Description: A logic issue existed in the handling of pageshow events. This issue was addressed with improved state management.
  • CVE-2017-2514
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2515
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2521
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2525
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to Kai Kang (4B5F5F4B) of Tencent’s Xuanwu Lab (tencent.com) working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2526
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to Kai Kang (4B5F5F4B) of Tencent’s Xuanwu Lab (tencent.com) working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2528
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to universal cross site scripting (UXSS). Description: A logic issue existed in the handling of WebKit cached frames. This issue was addressed with improved state management.
  • CVE-2017-2530
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to Wei Yuan of Baidu Security Lab.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2531
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2536
    • Versions affected: WebKitGTK+ before 2.16.1.
    • 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 or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2539
    • Versions affected: WebKitGTK+ before 2.16.3.
    • 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 or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2544
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to 360 Security (@mj0011sec) working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2547
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to lokihardt of Google Project Zero, Team Sniper (Keen Lab and PC Mgr) working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-2549
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to universal cross site scripting (UXSS). Description: A logic issue existed in frame loading. This issue was addressed with improved state management.
  • CVE-2017-6980
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). Description: Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2017-6984
    • Versions affected: WebKitGTK+ before 2.16.1.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution or cause a denial of service (memory corruption and application crash). 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

May 25, 2017 12:00 AM



May 24, 2017

WebKitGTK+ 2.16.3 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.16.3 release?

  • Fix URL shown in the title of beforeunload dialogs.
  • Focus first input field of HTTP authentication dialog.
  • Fix rendering glitches in HiDPI in long GitHub Gist pages when focusing the comments textarea.
  • Remove Firefox user agent quirk for Google domains.
  • Remove LATEST_RECORD_VERSION from GnuTLS priority string.
  • Fix several crashes and rendering issues.
  • Security fixes: CVE-2017-2496, CVE-2017-2539, CVE-2017-2510.

Thanks to all the contributors who made possible this release.

May 24, 2017 12:00 AM



May 22, 2017

WebKitGTK+ 2.17.3 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.18 series.

What’s new in the WebKitGTK+ 2.17.3 release?

  • Add new API to create a WebKitContextMenuItem from a GAction.
  • Fix graphics repaint hungs in accelerated compositing mode after a resize.
  • Fix rendering glitches in HiDPI in long GitHub Gist pages when focusing the comments textarea.
  • Remove Firefox user agent quirk for Google domains.
  • Remove LATEST_RECORD_VERSION from GnuTLS priority string.
  • Improve colors of inspector SVG icons.
  • Fix several crashes and rendering issues.
  • Translation updates: French.

Thanks to all the contributors who made possible this release.

May 22, 2017 12:00 AM



May 11, 2017

WebKitGTK+ 2.17.2 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.18 series.

What’s new in the WebKitGTK+ 2.17.2 release?

  • Update user agent quirks to make Youtube and new Google login page work.
  • Fix URL shown in the title of beforeunload dialogs.
  • Focus first input field of HTTP authentication dialog.
  • Fix rendering of PNG images when decoded in more than one chunk.
  • Update several web inspector icons.
  • Fix the build with OpenGL disabled.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

May 11, 2017 12:00 AM



May 09, 2017

WebKitGTK+ 2.16.2 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.16.2 release?

  • Update user agent quirks to make Youtube and new Google login page work.
  • Fix rendering of animated PNGs.
  • Fix playing of some live streams.
  • Update several web inspector icons.
  • Fix the build with NPAPI plugins enabled but X11 disabled.
  • Fix the build with OpenGL disabled.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

May 09, 2017 12:00 AM



WebKitGTK+ 2.14.7 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.14.7 release?

  • Update user agent quirks to make Youtube and new Google login page work.
  • Fix playing of some live streams.

Thanks to all the contributors who made possible this release.

May 09, 2017 12:00 AM



May 03, 2017

Can I use CSS Box Alignment ?

by Javier Fernández

As a member of the Igalia’s team implementing the CSS Grid Layout feature for Blink and WebKit rendering engines, I’m very proud of what we’ve achieved from our collaboration with Bloomberg. I think Grid is a very interesting feature for the Web Platform and we still can’t see all its potential.

One of my main assignments on this project is to implement the CSS Box Alignment spec for Grid. It’s obvious that alignment is an important feature for many cases in web development, but I consider it a key for a layout model like the one Grid provides.

We recently announced that the patch implementing the self-baseline alignment landed in Blink. This was the last alignment functionality pending to implement, so now we can consider that the spec is complete for Grid. However, implementing a feature like CSS Box Alignment has an additional complexity in the form of interoperability issues.

Interoperability is always a challenge when implementing any new specification, but I think it’s specially problematic for a feature like this for several reasons:

  • The feature applies to several layout models.
  • The CSS Flexible Box specification already defined some of the CSS properties and values.
  • Once a new layout model implements the new specification, Flexbox is forced to follow it as well.

I admit that the editors of this new specification document made a huge effort to keep backward compatibility with the Flexbox spec (which caused not so few implementation challenges). However, the current Flexbox implementation of the CSS properties and values that both specs have in common would become a Partial Implementation regarding the new spec.

Recently Florian Rivoal found out that this partial implementation of the CSS Box Alignment feature prevents the use of cascade or @support for providing customized fallbacks for the unimplemented Alignment properties.

What does Partial Implementation actually mean ?

As anybody can imagine, implementing a fancy web feature takes a considerable amount of time. During this period, the feature passes through several phases with different exposure to the end users. It’s precisely due to the importance of end user’s feedback that these new web features are shipped under experimental flags. This workflow is specially useful no only for browser devs but for the spec editors as well.

For this reason, the W3C CSS Working Group defines a general policy to manage Partial Implementations, which can be summarized as follows:

So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support. In particular, user agents must not selectively ignore unsupported property values and honor supported values in a single multi-value property declaration: if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.

This policy is added to every spec as part of its Conformance appendix, so it is in the case of the CSS Box Alignment specification document. However, the interpretation of the Partial Implementation policy is far from trivial, specially for a feature like CSS Box Alignment. The most restrictive interpretation would imply the following facts:

  • Any new CSS property of the new spec should be declared invalid until is supported by all the layout models it applies to.
  • Any of the already existent CSS properties with new values defined in the new spec should be declared invalid until all these new values are implemented in all the layout models such property applies to.
  • Browsers shouldn’t ship (without experimental flags) any CSS property or value until it’s implemented in all the layout model it applies to.

When we discussed about this at Igalia we applied a less restrictive interpretation, based on the assumption that the spec actually defined several features which could be implemented and shipped independently, obviously avoiding any browsers interoperability issues. As it’s been always in the nature of the specification, keeping backward compatibility with Flexbox implementations has been a must, since its spec already defines some of the CSS properties now present in the new spec.

The issue filed by Florian was discussed during the Tokyo F2F Apr 19-21 2017 meeting, where it was agreed to add a new section in the CSS Box Alignment spec to clarify how implementors of this feature should manage Partial Implementations:

Since it is expected that support for the features in this module will be deployed in stages corresponding to the various layout models affected, it is hereby clarified that the rules for partial implementations that require treating as invalid any unsupported feature apply to any alignment keyword which is not supported across all layout modules to which it applies for layout models in which the implementation supports the property in general.

The new text added makes the Partial Implementation policy less restrictive and, even it contradicts our interpretation of independent alignment features per layout model, it affects only to models which already implement any of the CSS properties defined in the new spec. In this case, only Flexbox has to be updated to implement the new values defined for its alignment related CSS properties: align-content, justify-content and align-self.

Analysis of the implementation and shipment status

Before thinking on how to address the Partial Implementation issues, I decided to analyze what’s the status of the CSS Box Alignment feature in the different browsers. If you are interested in the full analysis, it’s available here. The following table shows the implementation status of the new spec in the Safary, Chrome and Firefox browsers, using a color code like unimplemented, only grid or both (flex and grid):

If you can try out some examples of these Partial Implementation issues, just try flexbox vs grid cases with some of these alignment values: align-items: center, align-self: left; align-content: start or justify-content: end.

The 3 major browsers analyzed have shipped most, if not all, the CSS Box Alignment spec implemented for CSS Grid Layout (since Chrome 57, Safari 10.1, Firefox 52). Firefox is the browser which implemented and shipped a wider support for CSS Flexible Box.

We can extract the following conclusions:

  • The 3 browsers analyzed have shipped Partial Implementations of the CSS Box Alignment specification, although Firefox is almost complete.
  • The 3 browsers have shipped a Grid feature that supports completely the new CSS Box Alignment spec, although Safari still misses the self-baseline values.
  • The 3 implementations of the new CSS Box Alignment specification are backward compatible with the CSS Flexible Box specification, even though it implements for some properties a lower level of the spec (e.g. self-baseline keywords)

Work in progress

Although we are still evaluating the problem together with the Blink and WebKit communities, at Igalia we are already working on improving the situation. We all agree on the damage to the Web Platform that these Partial Implementation issues are causing, as Florian pointed out initially, so that’s a good starting point. There are bug reports on both WebKit and Blink and we are already providing patches for some of them.

We are still discussing about the best approach, but our bet would be to request an intent-to-implement-and-ship for a CSS Box Alignment (for flexbox layout) feature. This approach fits naturally in our initial plans of implementing several independent features from the alignment specification. It seems that it’s what Firefox is doing, which already announced the implementation of CSS Box Alignment (for block layout)

Thanks to Bloomberg for sponsoring this work, as part of the efforts that Igalia has been doing all these years pursuing a better and more open web.

Igalia & Bloomberg logos

by jfernandez at May 03, 2017 08:19 PM



WebKitGTK+ remote debugging in 2.18

by Carlos García Campos

WebKitGTK+ has supported remote debugging for a long time. The current implementation uses WebSockets for the communication between the local browser (the debugger) and the remote browser (the debug target or debuggable). This implementation was very simple and, in theory, you could use any web browser as the debugger because all inspector code was served by the WebSockets. I said in theory because in the practice this was not always so easy, since the inspector code uses newer JavaScript features that are not implemented in other browsers yet. The other major issue of this approach was that the communication between debugger and target was not bi-directional, so the target browser couldn’t notify the debugger about changes (like a new tab open, navigation or that is going to be closed).

Apple abandoned the WebSockets approach a long time ago and implemented its own remote inspector, using XPC for the communication between debugger and target. They also moved the remote inspector handling to JavaScriptCore making it available to debug JavaScript applications without a WebView too. In addition, the remote inspector is also used by Apple to implement WebDriver. We think that this approach has a lot more advantages than disadvantages compared to the WebSockets solution, so we have been working on making it possible to use this new remote inspector in the GTK+ port too. After some refactorings to the code to separate the cross-platform implementation from the Apple one, we could add our implementation on top of that. This implementation is already available in WebKitGTK+ 2.17.1, the first unstable release of this cycle.

From the user point of view there aren’t many differences, with the WebSockets we launched the target browser this way:

$ WEBKIT_INSPECTOR_SERVER=127.0.0.1:1234 browser

This hasn’t changed with the new remote inspector. To start debugging we opened any browser and loaded

http://127.0.0.1:1234

With the new remote inspector we have to use any WebKitGTK+ based browser and load

inspector://127.0.0.1:1234

As you have already noticed, it’s no longer possible to use any web browser, you need to use a recent enough WebKitGTK+ based browser as the debugger. This is because of the way the new remote inspector works. It requires a frontend implementation that knows how to communicate with the targets. In the case of Apple that frontend implementation is Safari itself, which has a menu with the list of remote debuggable targets. In WebKitGTK+ we didn’t want to force using a particular web browser as debugger, so the frontend is implemented as a builtin custom protocol of WebKitGTK+. So, loading inspector:// URLs in any WebKitGTK+ WebView will show the remote inspector page with the list of debuggable targets.

It looks quite similar to what we had, just a list of debuggable targets, but there are a few differences:

  • A new debugger window is opened when inspector button is clicked instead of reusing the same web view. Clicking on inspect again just brings the window to the front.
  • The debugger window loads faster, because the inspector code is not served by HTTP, but locally loaded like the normal local inspector.
  • The target list page is updated automatically, without having to manually reload it when a target is added, removed or modified.
  • The debugger window is automatically closed when the target web view is closed or crashed.

How does the new remote inspector work?

The web browser checks the presence of WEBKIT_INSPECTOR_SERVER environment variable at start up, the same way it was done with the WebSockets. If present, the RemoteInspectorServer is started in the UI process running a DBus service listening in the IP and port provided. The environment variable is propagated to the child web processes, that create a RemoteInspector object and connect to the RemoteInspectorServer. There’s one RemoteInspector per web process, and one debuggable target per WebView. Every RemoteInspector maintains a list of debuggable targets that is sent to the RemoteInspector server when a new target is added, removed or modified, or when explicitly requested by the RemoteInspectorServer.
When the debugger browser loads an inspector:// URL, a RemoteInspectorClient is created. The RemoteInspectorClient connects to the RemoteInspectorServer using the IP and port of the inspector:// URL and asks for the list of targets that is used by the custom protocol handler to create the web page. The RemoteInspectorServer works as a router, forwarding messages between RemoteInspector and RemoteInspectorClient objects.

by carlos garcia campos at May 03, 2017 03:43 PM



WebKitGTK+ 2.17.1 released!

by The WebKitGTK+ Project

This is the first development release leading toward 2.18 series.

What’s new in the WebKitGTK+ 2.17.1 release?

  • Switch to use new remote inspector infraestructure instead of legacy Web Sockets based one.
  • Add API to enable and handle Web Automation.
  • Load large images asynchronously off the main theead.
  • Use GtkFileChooserNative for open/save dialogs when available.
  • Make file chooser run as modal by default if possible.
  • Fix position of dropdown menus in Wayland.
  • Keep URI fragments after a server redirection.
  • Implement support for aria-haspopup and aria-autocomplete.
  • Implement aria-value support for focusable separators.
  • Fix playing of some live streams.

Thanks to all the contributors who made possible this release.

May 03, 2017 12:00 AM



April 06, 2017

WebKitGTK+ Security Advisory WSA-2017-0003

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2016-9642
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Gustavo Grieco.
    • JavaScriptCore in WebKit allows attackers to cause a denial of service (out-of-bounds heap read) via a crafted Javascript file.
  • CVE-2016-9643
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Gustavo Grieco.
    • The regex code in WebKit allows remote attackers to cause a denial of service (memory consumption) as demonstrated in a large number of ($ (open parenthesis and dollar) followed by {-2,16} and a large number of +) (plus close parenthesis).
  • CVE-2017-2364
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to bypass the Same Origin Policy and obtain sensitive information via a crafted web site.
  • CVE-2017-2367
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to bypass the Same Origin Policy and obtain sensitive information via a crafted web site.
  • CVE-2017-2376
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to an anonymous researcher, Chris Hlady of Google Inc, Yuyang Zhou of Tencent Security Platform Department (security.tencent.com), Muneaki Nishimura (nishimunea) of Recruit Technologies Co., Ltd., Michal Zalewski of Google Inc, an anonymous researcher.
    • This issue allows remote attackers to spoof the address bar by leveraging text input during the loading of a page.
  • CVE-2017-2377
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Vicki Pfau.
    • This issue involves the “WebKit Web Inspector” component. It allows attackers to cause a denial of service (memory corruption and application crash) by leveraging a window-close action during a debugger-pause state.
  • CVE-2017-2386
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to André Bargull.
    • This issue allows remote attackers to bypass the Same Origin Policy and obtain sensitive information via a crafted web site.
  • CVE-2017-2392
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Max Bazaliy of Lookout.
    • This issue allows attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted app.
  • CVE-2017-2394
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Apple.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2395
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Apple.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2396
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Apple.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2405
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Apple.
    • This issue involves the “WebKit Web Inspector” component. It allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2415
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Kai Kang of Tencent’s Xuanwu Lab (tentcent.com).
    • This issue allows remote attackers to execute arbitrary code by leveraging an unspecified “type confusion.”.
  • CVE-2017-2419
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Nicolai Grødum of Cisco Systems.
    • This issue allows remote attackers to bypass a Content Security Policy protection mechanism via unspecified vectors.
  • CVE-2017-2433
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Apple.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2442
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to lokihardt of Google Project Zero.
    • This issue involves the “WebKit JavaScript Bindings” component. It allows remote attackers to bypass the Same Origin Policy and obtain sensitive information via a crafted web site.
  • CVE-2017-2445
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to conduct Universal XSS (UXSS) attacks via crafted frame objects.
  • CVE-2017-2446
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Natalie Silvanovich of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code via a crafted web site that leverages the mishandling of strict mode functions.
  • CVE-2017-2447
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Natalie Silvanovich of Google Project Zero.
    • This issue allows remote attackers to obtain sensitive information or cause a denial of service (memory corruption) via a crafted web site.
  • CVE-2017-2454
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Ivan Fratric of Google Project Zero.
    • This issue allows allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2455
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Ivan Fratric of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2457
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2459
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Ivan Fratric of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2460
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Ivan Fratric of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2464
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to Jeonghoon Shin, Natalie Silvanovich of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2465
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Zheng Huang and Wei Yuan of Baidu Security Lab.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2466
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Ivan Fratric of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2468
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2469
    • Versions affected: WebKitGTK+ before 2.16.0.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2470
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2471
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Ivan Fratric of Google Project Zero.
    • A use-after-free vulnerability allows remote attackers to execute arbitrary code via a crafted web site.
  • CVE-2017-2475
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to lokihardt of Google Project Zero.
    • This issue allows remote attackers to conduct Universal XSS (UXSS) attacks via crafted use of frames on a web site.
  • CVE-2017-2476
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to Ivan Fratric of Google Project Zero.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.
  • CVE-2017-2481
    • Versions affected: WebKitGTK+ before 2.14.6.
    • Credit to 0011 working with Trend Micro’s Zero Day Initiative.
    • This issue allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) via a crafted web site.

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 06, 2017 12:00 AM



WebKitGTK+ 2.14.6 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.14.6 release?

Thanks to all the contributors who made possible this release.

April 06, 2017 12:00 AM