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 20, 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 20, 2017 10:30 PM



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



April 04, 2017

WebKitGTK+ 2.16.1 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.16.1 release?

  • Fix no-third-party cookies policy in case of redirections.
  • Keep URL fragments after server redirections.
  • Honor GTK+ font settings.
  • Ensure depth and stencil renderbuffers are created on GLESv2.
  • Prevent new navigations from onbeforeunload handler and document unload.
  • Disallow beforeunload alerts from web pages users have never interacted with.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

April 04, 2017 12:00 AM



March 24, 2017

A Web Browser for Awesome People (Epiphany 3.24)

by Michael Catanzaro

Are you using a sad web browser that integrates poorly with GNOME or elementary OS? Was your sad browser’s GNOME integration theme broken for most of the past year? Does that make you feel sad? Do you wish you were using an awesome web browser that feels right at home in your chosen desktop instead? If so, Epiphany 3.24 might be right for you. It will make you awesome. (Ask your doctor before switching to a new web browser. Results not guaranteed. May cause severe Internet addiction. Some content unsuitable for minors.)

Epiphany was already awesome before, but it just keeps getting better. Let’s look at some of the most-noticeable new features in Epiphany 3.24.

You Can Load Webpages!

Yeah that’s a great start, right? But seriously: some people had trouble with this before, because it was not at all clear how to get to Epiphany’s address bar. If you were in the know, you knew all you had to do was click on the title box, then the address bar would appear. But if you weren’t in the know, you could be stuck. I made the executive decision that the title box would have to go unless we could find a way to solve the discoverability problem, and wound up following through on removing it. Now the address bar is always there at the top of the screen, just like in all those sad browsers. This is without a doubt our biggest user interface change:

Screenshot showing address bar visible
Discover GNOME 3! Discover the address bar!

You Can Set a Homepage!

A very small subset of users have complained that Epiphany did not allow setting a homepage, something we removed several years back since it felt pretty outdated. While I’m confident that not many people want this, there’s not really any good reason not to allow it — it’s not like it’s a huge amount of code to maintain or anything — so you can now set a homepage in the preferences dialog, thanks to some work by Carlos García Campos and myself. Retro! Carlos has even added a home icon to the header bar, which appears when you have a homepage set. I honestly still don’t understand why having a homepage is useful, but I hope this allows a wider audience to enjoy Epiphany.

New Bookmarks Interface

There is now a new star icon in the address bar for bookmarking pages, and another new icon for viewing bookmarks. Iulian Radu gutted our old bookmarks system as part of his Google Summer of Code project last year, replacing our old and seriously-broken bookmarks dialog with something much, much nicer. (He also successfully completed a major refactoring of non-bookmarks code as part of his project. Thanks Iulian!) Take a look:

Manage Tons of Tabs

One of our biggest complaints was that it’s hard to manage a large number of tabs. I spent a few hours throwing together the cheapest-possible solution, and the result is actually pretty decent:

Firefox has an equivalent feature, but Chrome does not. Ours is not perfect, since unfortunately the menu is not scrollable, so it still fails if there is a sufficiently-huge number of tabs. (This is actually surprisingly-difficult to fix while keeping the menu a popover, so I’m considering switching it to a traditional non-popover menu as a workaround. Help welcome.) But it works great up until the point where the popover is too big to fit on your monitor.

Note that the New Tab button has been moved to the right side of the header bar when there is only one tab open, so it has less distance to travel to appear in the tab bar when there are multiple open tabs.

Improved Tracking Protection

I modified our adblocker — which has been enabled by default for years — to subscribe to the EasyPrivacy filters provided by EasyList. You can disable it in preferences if you need to, but I haven’t noticed any problems caused by it, so it’s enabled by default, not just in incognito mode. The goal is to compete with Firefox’s Disconnect feature. How well does it work compared to Disconnect? I have no clue! But EasyPrivacy felt like the natural solution, since we already have an adblocker that supports EasyList filters.

Disclaimer: tracking protection on the Web is probably a losing battle, and you absolutely must use the Tor Browser Bundle if you really need anonymity. (And no, configuring Epiphany to use Tor is not clever, it’s very dumb.) But EasyPrivacy will at least make life harder for trackers.

Insecure Password Form Warning

Recently, Firefox and Chrome have started displaying security warnings  on webpages that contain password forms but do not use HTTPS. Now, we do too:

I had a hard time selecting the text to use for the warning. I wanted to convey the near-certainty that the insecure communication is being intercepted, but I wound up using the word “cybercriminal” when it’s probably more likely that your password is being gobbled up by various  governments. Feel free to suggest changes for 3.26 in the comments.

New Search Engine Manager

Cedric Le Moigne spent a huge amount of time gutting our smart bookmarks code — which allowed adding custom search engines to the address bar dropdown in a convoluted manner that involved creating a bookmark and manually adding %s into its URL — and replacing it with an actual real search engine manager that’s much nicer than trying to add a search engine via bookmarks. Even better, you no longer have to drop down to the command line in order to change the default search engine to something other than DuckDuckGo, Google, or Bing. Yay!

New Icon

Jakub Steiner and Lapo Calamandrei created a great new high-resolution app icon for Epiphany, which makes its debut in 3.24. Take a look.

WebKitGTK+ 2.16

WebKitGTK+ 2.16 improvements are not really an Epiphany 3.24 feature, since users of older versions of Epiphany can and must upgrade to WebKitGTK+ 2.16 as well, but it contains some big improvements that affect Epiphany. (For example, Žan Doberšek landed an important fix for JavaScript garbage collection that has resulted in massive memory reductions in long-running web processes.) But sometimes WebKit improvements are necessary for implementing new Epiphany features. That was true this cycle more than ever. For example:

  • Carlos García added a new ephemeral mode API to WebKitGTK+, and modified Epiphany to use it in order to make incognito mode much more stable and robust, avoiding corner cases where your browsing data could be leaked on disk.
  • Carlos García also added a new website data API to WebKitGTK+, and modified Epiphany to use it in the clear data dialog and cookies dialog. There are no user-visible changes in the cookies dialog, but the clear data dialog now exposes HTTP disk cache, HTML local storage, WebSQL, IndexedDB, and offline web application cache. In particular, local storage and the two databases can be thought of as “supercookies”: methods of storing arbitrary data on your computer for tracking purposes, which persist even when you clear your cookies. Unfortunately it’s still not possible to protect against this tracking, but at least you can view and delete it all now, which is not possible in Chrome or Firefox.
  • Sergio Villar Senin added new API to WebKitGTK+ to improve form detection, and modified Epiphany to use it so that it can now remember passwords on more websites. There’s still room for improvement here, but it’s a big step forward.
  • I added new API to WebKitGTK+ to improve how we handle giving websites permission to display notifications, and hooked it up in Epiphany. This fixes notification requests appearing inappropriately on websites like the https://riot.im/app/.

Notice the pattern? When there’s something we need to do in Epiphany that requires changes in WebKit, we make it happen. This is a lot more work, but it’s better for both Epiphany and WebKit in the long run. Read more about WebKitGTK+ 2.16 on Carlos García’s blog.

Future Features

Unfortunately, a couple exciting Epiphany features we were working on did not make the cut for Epiphany 3.24. The first is Firefox Sync support. This was developed by Gabriel Ivașcu during his Google Summer of Code project last year, and it’s working fairly well, but there are still a few problems. First, our current Firefox Sync code is only able to sync bookmarks, but we really want it to sync much more before releasing the feature: history and open tabs at the least. Also, although it uses Mozilla’s sync server (please thank Mozilla for their quite liberal terms of service allowing this!), it’s not actually compatible with Firefox. You can sync your Epiphany bookmarks between different Epiphany browser instances using your Firefox account, which is great, but we expect users will be quite confused that they do not sync with your Firefox bookmarks, which are stored separately. Some things, like preferences, will never be possible to sync with Firefox, but we can surely share bookmarks. Gabriel is currently working to address these issues while participating in the Igalia Coding Experience program, and we’re hopeful that sync support will be ready for prime time in Epiphany 3.26.

Also missing is HTTPS Everywhere support. It’s mostly working properly, thanks to lots of hard work from Daniel Brendle (grindhold) who created the libhttpseverywhere library we use, but it breaks a few websites and is not really robust yet, so we need more time to get this properly integrated into Epiphany. The goal is to make sure outdated HTTPS Everywhere rulesets do not break websites by falling back automatically to use of plain, insecure HTTP when a load fails. This will be much less secure than upstream HTTPS Everywhere, but websites that care about security ought to be redirecting users to HTTPS automatically (and also enabling HSTS). Our use of HTTPS Everywhere will just be to gain a quick layer of protection against passive attackers. Otherwise, we would not be able to enable it by default, since the HTTPS Everywhere rulesets are just not reliable enough. Expect HTTPS Everywhere to land for Epiphany 3.26.

Help Out

Are you a computer programmer? Found something less-than-perfect about Epiphany? We’re open for contributions, and would really appreciate it if you would try to fix that bug or add that feature instead of slinking back to using a less-awesome web browser. One frequently-requested feature is support for extensions. This is probably not going to happen anytime soon — we’d like to support WebExtensions, but that would be a huge effort — but if there’s some extension you miss from a sadder browser, ask if we’d allow building it into Epiphany as a regular feature. Replacements for popular extensions like NoScript and Greasemonkey would certainly be welcome.

Not a computer programmer? You can still help by reporting bugs on GNOME Bugzilla. If you have a crash to report, learn how to generate a good-quality stack trace so that we can try to fix it. I’ve credited many programmers for their work on Epiphany 3.24 up above, but programming work only gets us so far if we don’t know about bugs. I want to give a shout-out here to Hussam Al-Tayeb, who regularly built the latest code over the course of the 3.24 development cycle and found lots of problems for us to fix. This release would be much less awesome if not for his testing.

OK, I’m done typing stuff now. Onwards to 3.26!

by Michael Catanzaro at March 24, 2017 01:18 AM



March 20, 2017

WebKitGTK+ 2.16

by Carlos García Campos

The Igalia WebKit team is happy to announce WebKitGTK+ 2.16. This new release drastically improves the memory consumption, adds new API as required by applications, includes new debugging tools, and of course fixes a lot of bugs.

Memory consumption

After WebKitGTK+ 2.14 was released, several Epiphany users started to complain about high memory usage of WebKitGTK+ when Epiphany had a lot of tabs open. As we already explained in a previous post, this was because of the switch to the threaded compositor, that made hardware acceleration always enabled. To fix this, we decided to make hardware acceleration optional again, enabled only when websites require it, but still using the threaded compositor. This is by far the major improvement in the memory consumption, but not the only one. Even when in accelerated compositing mode, we managed to reduce the memory required by GL contexts when using GLX, by using OpenGL version 3.2 (core profile) if available. In mesa based drivers that means that software rasterizer fallback is never required, so the context doesn’t need to create the software rasterization part. And finally, an important bug was fixed in the JavaScript garbage collector timers that prevented the garbage collection to happen in some cases.

CSS Grid Layout

Yes, the future here and now available by default in all WebKitGTK+ based browsers and web applications. This is the result of several years of great work by the Igalia web platform team in collaboration with bloomberg. If you are interested, you have all the details in Manuel’s blog.

New API

The WebKitGTK+ API is quite complete now, but there’s always new things required by our users.

Hardware acceleration policy

Hardware acceleration is now enabled on demand again, when a website requires to use accelerated compositing, the hardware acceleration is enabled automatically. WebKitGTK+ has environment variables to change this behavior, WEBKIT_DISABLE_COMPOSITING_MODE to never enable hardware acceleration and WEBKIT_FORCE_COMPOSITING_MODE to always enabled it. However, those variables were never meant to be used by applications, but only for developers to test the different code paths. The main problem of those variables is that they apply to all web views of the application. Not all of the WebKitGTK+ applications are web browsers, so it can happen that an application knows it will never need hardware acceleration for a particular web view, like for example the evolution composer, while other applications, especially in the embedded world, always want hardware acceleration enabled and don’t want to waste time and resources with the switch between modes. For those cases a new WebKitSetting hardware-acceleration-policy has been added. We encourage everybody to use this setting instead of the environment variables when upgrading to WebKitGTk+ 2.16.

Network proxy settings

Since the switch to WebKit2, where the SoupSession is no longer available from the API, it hasn’t been possible to change the network proxy settings from the API. WebKitGTK+ has always used the default proxy resolver when creating the soup context, and that just works for most of our users. But there are some corner cases in which applications that don’t run under a GNOME environment want to provide their own proxy settings instead of using the proxy environment variables. For those cases WebKitGTK+ 2.16 includes a new UI process API to configure all proxy settings available in GProxyResolver API.

Private browsing

WebKitGTK+ has always had a WebKitSetting to enable or disable the private browsing mode, but it has never worked really well. For that reason, applications like Epiphany has always implemented their own private browsing mode just by using a different profile directory in tmp to write all persistent data. This approach has several issues, for example if the UI process crashes, the profile directory is leaked in tmp with all the personal data there. WebKitGTK+ 2.16 adds a new API that allows to create ephemeral web views which never write any persistent data to disk. It’s possible to create ephemeral web views individually, or create ephemeral web contexts where all web views associated to it will be ephemeral automatically.

Website data

WebKitWebsiteDataManager was added in 2.10 to configure the default paths on which website data should be stored for a web context. In WebKitGTK+ 2.16 the API has been expanded to include methods to retrieve and remove the website data stored on the client side. Not only persistent data like HTTP disk cache, cookies or databases, but also non-persistent data like the memory cache and session cookies. This API is already used by Epiphany to implement the new personal data dialog.

Dynamically added forms

Web browsers normally implement the remember passwords functionality by searching in the DOM tree for authentication form fields when the document loaded signal is emitted. However, some websites add the authentication form fields dynamically after the document has been loaded. In those cases web browsers couldn’t find any form fields to autocomplete. In WebKitGTk+ 2.16 the web extensions API includes a new signal to notify when new forms are added to the DOM. Applications can connect to it, instead of document-loaded to start searching for authentication form fields.

Custom print settings

The GTK+ print dialog allows the user to add a new tab embedding a custom widget, so that applications can include their own print settings UI. Evolution used to do this, but the functionality was lost with the switch to WebKit2. In WebKitGTK+ 2.16 a similar API to the GTK+ one has been added to recover that functionality in evolution.

Notification improvements

Applications can now set the initial notification permissions on the web context to avoid having to ask the user everytime. It’s also possible to get the tag identifier of a WebKitNotification.

Debugging tools

Two new debugged tools are now available in WebKitGTk+ 2.16. The memory sampler and the resource usage overlay.

Memory sampler

This tool allows to monitor the memory consumption of the WebKit processes. It can be enabled by defining the environment variable WEBKIT_SMAPLE_MEMORY. When enabled, the UI process and all web process will automatically take samples of memory usage every second. For every sample a detailed report of the memory used by the process is generated and written to a file in the temp directory.

$ WEBKIT_SAMPLE_MEMORY=1 MiniBrowser 
Started memory sampler for process MiniBrowser 32499; Sampler log file stored at: /tmp/MiniBrowser7ff2246e-406e-4798-bc83-6e525987aace
Started memory sampler for process WebKitWebProces 32512; Sampler log file stored at: /tmp/WebKitWebProces93a10a0f-84bb-4e3c-b257-44528eb8f036

The files contain a list of sample reports like this one:

Timestamp                          1490004807
Total Program Bytes                1960214528
Resident Set Bytes                 84127744
Resident Shared Bytes              68661248
Text Bytes                         4096
Library Bytes                      0
Data + Stack Bytes                 87068672
Dirty Bytes                        0
Fast Malloc In Use                 86466560
Fast Malloc Committed Memory       86466560
JavaScript Heap In Use             0
JavaScript Heap Committed Memory   49152
JavaScript Stack Bytes             2472
JavaScript JIT Bytes               8192
Total Memory In Use                86477224
Total Committed Memory             86526376
System Total Bytes                 16729788416
Available Bytes                    5788946432
Shared Bytes                       1037447168
Buffer Bytes                       844214272
Total Swap Bytes                   1996484608
Available Swap Bytes               1991532544

Resource usage overlay

The resource usage overlay is only available in Linux systems when WebKitGTK+ is built with ENABLE_DEVELOPER_MODE. It allows to show an overlay with information about resources currently in use by the web process like CPU usage, total memory consumption, JavaScript memory and JavaScript garbage collector timers information. The overlay can be shown/hidden by pressing CTRL+Shit+G.

We plan to add more information to the overlay in the future like memory cache status.

by carlos garcia campos at March 20, 2017 03:19 PM



WebKitGTK+ 2.16.0 released!

by The WebKitGTK+ Project

This is the first stable release in the 2.16 series.

Highlights of the WebKitGTK+ 2.16.0 release

  • Hardware acceleration is now enabled on demand to drastically reduce memory consumption.
  • CSS Grid Layout is enabled by default.
  • New WebKitSetting to set the hardware acceleration policy.
  • UI process API to configure network proxy settings.
  • Improved private browsing by adding new API to create ephemeral web views.
  • New API to handle website data.
  • Debug tools: memory sampler and resource usage overlay

For more details about all the changes included in WebKitGTK+ 2.16 see the NEWS file that is included in the tarball, or see:

http://blogs.igalia.com/carlosgc/2017/03/20/webkitgtk-2-16/

Thanks to all the contributors who made possible this release.

March 20, 2017 12:00 AM



March 14, 2017

WebKitGTK+ 2.15.92 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.16 series.

What’s new in the WebKitGTK+ 2.15.92 release?

  • Show the context menu when triggered by the keyboard.
  • Fix web process deadlocks when destroying the media player.
  • Fix web process crashes when loading animated GIFs.
  • Fix several crashes and rendering issues.
  • Translation updates: Polish.

Thanks to all the contributors who made possible this release.

March 14, 2017 12:00 AM



March 01, 2017

WebKitGTK+ 2.15.91 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.16 series.

What’s new in the WebKitGTK+ 2.15.91 release?

  • Fix rendering artifacts when resizing the window in accelerated compositing mode.
  • Remove flickering when leaving accelerated compositing mode.
  • Fix a web process crash when loading duck duck go.
  • Properly handle copy drag and drop operations.
  • Fix a hang when sending an IPC messages fails because socket read buffers are full.
  • Ensure we never try to load GTK2 plugins in Wayland.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

March 01, 2017 12:00 AM



February 20, 2017

WebKitGTK+ 2.15.90 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.16 series.

What’s new in the WebKitGTK+ 2.15.90 release?

  • Add an API to add a custom tab into the print dialog.
  • Update cookie manager API to properly work with ephemeral sessions.
  • Fix rendering issues in long documents with transparent background.
  • Handle extended colors in cairo and texture mapper backends.
  • Release unused UpdateAtlas and reduce the tile coverage on memory pressure.
  • The media backend now stores preloaded media in /var/tmp instead of user cache dir.
  • Fix a deadlock when the media player is destroyed.
  • Fast replay on video hide/unhide on platforms with limited video buffer pools.
  • Fix network process crashes when loading custom URI schemes.
  • Fix video rendering when switching to accelerated compositing mode.
  • Fix several crashes and rendering issues.
  • Translation updates: Brazilian Portuguese.

Thanks to all the contributors who made possible this release.

February 20, 2017 12:00 AM



February 15, 2017

WebKitGTK+ 2.14.5 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.5 release?

  • Fix rendering of non-accelerated contents with HiDPI.
  • Revert the fix for rendering issues in long documents with transparent background because it caused issues in HiDPI.

Thanks to all the contributors who made possible this release.

February 15, 2017 12:00 AM



February 10, 2017

Accelerated compositing in WebKitGTK+ 2.14.4

by Carlos García Campos

WebKitGTK+ 2.14 release was very exciting for us, it finally introduced the threaded compositor to drastically improve the accelerated compositing performance. However, the threaded compositor imposed the accelerated compositing to be always enabled, even for non-accelerated contents. Unfortunately, this caused different kind of problems to several people, and proved that we are not ready to render everything with OpenGL yet. The most relevant problems reported were:

  • Memory usage increase: OpenGL contexts use a lot of memory, and we have the compositor in the web process, so we have at least one OpenGL context in every web process. The threaded compositor uses the coordinated graphics model, that also requires more memory than the simple mode we previously use. People who use a lot of tabs in epiphany quickly noticed that the amount of memory required was a lot more.
  • Startup and resize slowness: The threaded compositor makes everything smooth and performs quite well, except at startup or when the view is resized. At startup we need to create the OpenGL context, which is also quite slow by itself, but also need to create the compositing thread, so things are expected to be slower. Resizing the viewport is the only threaded compositor task that needs to be done synchronously, to ensure that everything is in sync, the web view in the UI process, the OpenGL viewport and the backing store surface. This means we need to wait until the threaded compositor has updated to the new size.
  • Rendering issues: some people reported rendering artifacts or even nothing rendered at all. In most of the cases they were not issues in WebKit itself, but in the graphic driver or library. It’s quite diffilcult for a general purpose web engine to support and deal with all possible GPUs, drivers and libraries. Chromium has a huge list of hardware exceptions to disable some OpenGL extensions or even hardware acceleration entirely.

Because of these issues people started to use different workarounds. Some people, and even applications like evolution, started to use WEBKIT_DISABLE_COMPOSITING_MODE environment variable, that was never meant for users, but for developers. Other people just started to build their own WebKitGTK+ with the threaded compositor disabled. We didn’t remove the build option because we anticipated some people using old hardware might have problems. However, it’s a code path that is not tested at all and will be removed for sure for 2.18.

All these issues are not really specific to the threaded compositor, but to the fact that it forced the accelerated compositing mode to be always enabled, using OpenGL unconditionally. It looked like a good idea, entering/leaving accelerated compositing mode was a source of bugs in the past, and all other WebKit ports have accelerated compositing mode forced too. Other ports use UI side compositing though, or target a very specific hardware, so the memory problems and the driver issues are not a problem for them. The imposition to force the accelerated compositing mode came from the switch to using coordinated graphics, because as I said other ports using coordinated graphics have accelerated compositing mode always enabled, so they didn’t care about the case of it being disabled.

There are a lot of long-term things we can to to improve all the issues, like moving the compositor to the UI (or a dedicated GPU) process to have a single GL context, implement tab suspension, etc. but we really wanted to fix or at least improve the situation for 2.14 users. Switching back to use accelerated compositing mode on demand is something that we could do in the stable branch and it would improve the things, at least comparable to what we had before 2.14, but with the threaded compositor. Making it happen was a matter of fixing a lot bugs, and the result is this 2.14.4 release. Of course, this will be the default in 2.16 too, where we have also added API to set a hardware acceleration policy.

We recommend all 2.14 users to upgrade to 2.14.4 and stop using the WEBKIT_DISABLE_COMPOSITING_MODE environment variable or building with the threaded compositor disabled. The new API in 2.16 will allow to set a policy for every web view, so if you still need to disable or force hardware acceleration, please use the API instead of WEBKIT_DISABLE_COMPOSITING_MODE and WEBKIT_FORCE_COMPOSITING_MODE.

We really hope this new release and the upcoming 2.16 will work much better for everybody.

by carlos garcia campos at February 10, 2017 05:18 PM



WebKitGTK+ Security Advisory WSA-2017-0002

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2017-2350
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to Gareth Heyes of Portswigger Web Security.
    • Impact: Processing maliciously crafted web content may exfiltrate data cross-origin. Description: A prototype access issue was addressed through improved exception handling.
  • CVE-2017-2354
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to Neymar 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. Description: Multiple memory corruption issues were addressed through improved memory handling.
  • CVE-2017-2355
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to Team Pangu and lokihardt at PwnFest 2016.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A memory initialization issue was addressed through improved memory handling.
  • CVE-2017-2356
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to Team Pangu and lokihardt at PwnFest 2016.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved input validation.
  • CVE-2017-2362
    • Versions affected: WebKitGTK+ before 2.14.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 through improved memory handling.
  • CVE-2017-2363
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may exfiltrate data cross-origin. Description: Multiple validation issues existed in the handling of page loading. This issue was addressed through improved logic.
  • CVE-2017-2364
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may exfiltrate data cross-origin. Description: Multiple validation issues existed in the handling of page loading. This issue was addressed through improved logic.
  • CVE-2017-2365
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to lokihardt of Google Project Zero.
    • Impact: Processing maliciously crafted web content may exfiltrate data cross-origin. Description: A validation issue existed in variable handling. This issue was addressed through improved validation.
  • CVE-2017-2366
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to Kai Kang 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 through improved input validation.
  • CVE-2017-2369
    • Versions affected: WebKitGTK+ before 2.14.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 through improved input validation.
  • CVE-2017-2371
    • Versions affected: WebKitGTK+ before 2.14.4.
    • Credit to lokihardt of Google Project Zero.
    • Impact: A malicious website can open popups. Description: An issue existed in the handling of blocking popups. This was addressed through improved input validation.
  • CVE-2017-2373
    • Versions affected: WebKitGTK+ before 2.14.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 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

February 10, 2017 12:00 AM



WebKitGTK+ 2.14.4 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.4 release?

  • Make accelerating compositing mode on-demand again. By default it will only be used for websites that require it, saving a lot of memory on websites that don’t need it.
  • Fix rendering issues in long documents with transparent background.
  • Release unused UpdateAtlas and reduce the tile coverage on memory pressure.
  • The media backend now stores preloaded media in /var/tmp instead of user cache dir.
  • Make inspector work again when accelerated compositing support is disabled.
  • Fix a deadlock when the media player is destroyed.
  • Fix network process crashes when loading custom URI schemes.
  • Fix overlay scrollbars that are over a subframe.
  • Fix a crash in GraphicsContext3D::drawArrays when using OpenGL 3.2 core profile.
  • Fix BadDamage X errors happening when resizing the WebView.
  • Fix several crashes and rendering issues.
  • Security fixes: CVE-2017-2365, CVE-2017-2366, CVE-2017-2373, CVE-2017-2363, CVE-2017-2362, CVE-2017-2350, CVE-2017-2350, CVE-2017-2354, CVE-2017-2355, CVE-2017-2356, CVE-2017-2371, CVE-2017-2364, CVE-2017-2369.

Thanks to all the contributors who made possible this release.

February 10, 2017 12:00 AM



February 08, 2017

An Update on WebKit Security Updates

by Michael Catanzaro

One year ago, I wrote a blog post about WebKit security updates that attracted a fair amount of attention at the time. For a full understanding of the situation, you really have to read the whole thing, but the most important point was that, while WebKitGTK+ — one of the two WebKit ports present in Linux distributions — was regularly releasing upstream security updates, most Linux distributions were ignoring the updates, leaving users vulnerable to various security bugs, mainly of the remote code execution variety. At the time of that blog post, only Arch Linux and Fedora were regularly releasing WebKitGTK+ updates, and Fedora had only very recently begun doing so comprehensively.

Progress report!

So how have things changed in the past year? The best way to see this is to look at the versions of WebKitGTK+ in currently-supported distributions. The latest version of WebKitGTK+ is 2.14.3, which fixes 13 known security issues present in 2.14.2. Do users of the most popular Linux operating systems have the fixes?

  • Fedora users are good. Both Fedora 24 and Fedora 25 have the latest version, 2.14.3.
  • If you use Arch, you know you always have the latest stuff.
  • Ubuntu users rejoice: 2.14.3 updates have been released to users of both Ubuntu 16.04 and 16.10. I’m very  pleased that Ubuntu has decided to take my advice and make an exception to its usual stable release update policy to ensure its users have a secure version of WebKit. I can’t give Ubuntu an A grade here because the updates tend to lag behind upstream by several months, but slow updates are much better than no updates, so this is undoubtedly a huge improvement. (Anyway, it’s hardly a bad idea to be cautious when releasing a big update with high regression potential, as is unfortunately the case with even stable WebKit updates.) But if you use the still-supported Ubuntu 14.04 or 12.04, be aware that these versions of Ubuntu cannot ever update WebKit, as it would require a switch to WebKit2, a major API change.
  • Debian does not update WebKit as a matter of policy. The latest release, Debian 8.7, is still shipping WebKitGTK+ 2.6.2. I count 184 known vulnerabilities affecting it, though that’s an overcount as we did not exclude some Mac-specific security issues from the 2015 security advisories. (Shipping ancient WebKit is not just a security problem, but a user experience problem too. Actually attempting to browse the web with WebKitGTK+ 2.6.2 is quite painful due to bugs that were fixed years ago, so please don’t try to pretend it’s “stable.”) Note that a secure version of WebKitGTK+ is available for those in the know via the backports repository, but this does no good for users who trust Debian to provide them with security updates by default without requiring difficult configuration. Debian testing users also currently have the latest 2.14.3, but you will need to switch to Debian unstable to get security updates for the foreseeable future, as testing is about to freeze.
  • For openSUSE users, only Tumbleweed has the latest version of WebKit. The current stable release, Leap 42.2, ships with WebKitGTK+ 2.12.5, which is coincidentally affected by exactly 42 known vulnerabilities. (I swear I am not making this up.) The previous stable release, Leap 42.1, originally released with WebKitGTK+ 2.8.5 and later updated to 2.10.7, but never past that. It is affected by 65 known vulnerabilities. (Note: I have to disclose that I told openSUSE I’d try to help out with that update, but never actually did. Sorry!) openSUSE has it a bit harder than other distros because it has decided to use SUSE Linux Enterprise as the source for its GCC package, meaning it’s stuck on GCC 4.8 for the foreseeable future, while WebKit requires GCC 4.9. Still, this is only a build-time requirement; it’s not as if it would be impossible to build with Clang instead, or a custom version of GCC. I would expect WebKit updates to be provided to both currently-supported Leap releases.
  • Gentoo has the latest version of WebKitGTK+, but only in testing. The latest version marked stable is 2.12.5, so this is a serious problem if you’re following Gentoo’s stable channel.
  • Mageia has been updating WebKit and released a couple security advisories for Mageia 5, but it seems to be stuck on 2.12.4, which is disappointing, especially since 2.12.5 is a fairly small update. The problem here does not seem to be lack of upstream release monitoring, but rather lack of manpower to prepare the updates, which is a typical problem for small distros.
  • The enterprise distros from Red Hat, Oracle, and SUSE do not provide any WebKit security updates. They suffer from the same problem as Ubuntu’s old LTS releases: the WebKit2 API change  makes updating impossible. See my previous blog post if you want to learn more about that. (SUSE actually does have WebKitGTK+ 2.12.5 as well, but… yeah, 42.)

So results are clearly mixed. Some distros are clearly doing well, and others are struggling, and Debian is Debian. Still, the situation on the whole seems to be much better than it was one year ago. Most importantly, Ubuntu’s decision to start updating WebKitGTK+ means the vast majority of Linux users are now receiving updates. Thanks Ubuntu!

To arrive at the above vulnerability totals, I just counted up the CVEs listed in WebKitGTK+ Security Advisories, so please do double-check my counting if you want. The upstream security advisories themselves are worth mentioning, as we have only been releasing these for two years now, and the first year was pretty rough when we lost our original security contact at Apple shortly after releasing the first advisory: you can see there were only two advisories in all of 2015, and the second one was huge as a result of that. But 2016 seems to have gone decently well. WebKitGTK+ has normally been releasing most security fixes even before Apple does, though the actual advisories and a few remaining fixes normally lag behind Apple by roughly a month or so. Big thanks to my colleagues at Igalia who handle this work.

Challenges ahead

There are still some pretty big problems remaining!

First of all, the distributions that still aren’t releasing regular WebKit updates should start doing so.

Next, we have to do something about QtWebKit, the other big WebKit port for Linux, which stopped receiving security updates in 2013 after the Qt developers decided to abandon the project. The good news is that Konstantin Tokarev has been working on a QtWebKit fork based on WebKitGTK+ 2.12, which is almost (but not quite yet) ready for use in distributions. I hope we are able to switch to use his project as the new upstream for QtWebKit in Fedora 26, and I’d encourage other distros to follow along. WebKitGTK+ 2.12 does still suffer from those 42 vulnerabilities, but this will be a big improvement nevertheless and an important stepping stone for a subsequent release based on the latest version of WebKitGTK+. (Yes, QtWebKit will be a downstream of WebKitGTK+. No, it will not use GTK+. It will work out fine!)

It’s also time to get rid of the old WebKitGTK+ 2.4 (“WebKit1”), which all distributions currently parallel-install alongside modern WebKitGTK+ (“WebKit2”). It’s very unfortunate that a large number of applications still depend on WebKitGTK+ 2.4 — I count 41 such packages in Fedora — but this old version of WebKit is affected by over 200 known vulnerabilities and really has to go sooner rather than later. We’ve agreed to remove WebKitGTK+ 2.4 and its dependencies from Fedora rawhide right after Fedora 26 is branched next month, so they will no longer be present in Fedora 27 (targeted for release in November). That’s bad for you if you use any of the affected applications, but fortunately most of the remaining unported applications are not very important or well-known; the most notable ones that are unlikely to be ported in time are GnuCash (which won’t make our deadline) and Empathy (which is ported in git master, but is not currently in a  releasable state; help wanted!). I encourage other distributions to follow our lead here in setting a deadline for removal. The alternative is to leave WebKitGTK+ 2.4 around until no more applications are using it. Distros that opt for this approach should be prepared to be stuck with it for the next 10 years or so, as the remaining applications are realistically not likely to be ported so long as zombie WebKitGTK+ 2.4 remains available.

These are surmountable problems, but they require action by downstream distributions. No doubt some distributions will be more successful than others, but hopefully many distributions will be able to fix these problems in 2017. We shall see!

by Michael Catanzaro at February 08, 2017 06:32 AM



On Epiphany Security Updates and Stable Branches

by Michael Catanzaro

One of the advantages of maintaining a web browser based on WebKit, like Epiphany, is that the vast majority of complexity is contained within WebKit. Epiphany itself doesn’t have any code for HTML parsing or rendering, multimedia playback, or JavaScript execution, or anything else that’s actually related to displaying web pages: all of the hard stuff is handled by WebKit. That means almost all of the security problems exist in WebKit’s code and not Epiphany’s code. While WebKit has been affected by over 200 CVEs in the past two years, and those issues do affect Epiphany, I believe nobody has reported a security issue in Epiphany’s code during that time. I’m sure a large part of that is simply because only the bad guys are looking, but the attack surface really is much, much smaller than that of WebKit. To my knowledge, the last time we fixed a security issue that affected a stable version of Epiphany was 2014.

Well that streak has unfortunately ended; you need to make sure to update to Epiphany 3.22.6, 3.20.7, or 3.18.11 as soon as possible (or Epiphany 3.23.5 if you’re testing our unstable series). If your distribution is not already preparing an update, insist that it do so. I’m not planning to discuss the embarrassing issue here — you can check the bug report if you’re interested — but rather on why I made new releases on three different branches. That’s quite unlike how we handle WebKitGTK+ updates! Distributions must always update to the very latest version of WebKitGTK+, as it is not practical to backport dozens of WebKit security fixes to older versions of WebKit. This is rarely a problem, because WebKitGTK+ has a strict policy to dictate when it’s acceptable to require new versions of runtime dependencies, designed to ensure roughly three years of WebKit updates without the need to upgrade any of its dependencies. But new major versions of Epiphany are usually incompatible with older releases of system libraries like GTK+, so it’s not practical or expected for distributions to update to new major versions.

My current working policy is to support three stable branches at once: the latest stable release (currently Epiphany 3.22), the previous stable release (currently Epiphany 3.20), and an LTS branch defined by whatever’s currently in Ubuntu LTS and elementary OS (currently Epiphany 3.18). It was nice of elementary OS to make Epiphany its default web browser, and I would hardly want to make it difficult for its users to receive updates.

Three branches can be annoying at times, and it’s a lot more than is typical for a GNOME application, but a web browser is not a typical application. For better or for worse, the majority of our users are going to be stuck on Epiphany 3.18 for a long time, and it would be a shame to leave them completely without updates. That said, the 3.18 and 3.20 branches are very stable and only getting bugfixes and occasional releases for the most serious issues. In contrast, I try to backport all significant bugfixes to the 3.22 branch and do a new release every month or thereabouts.

So that’s why I just released another update for Epiphany 3.18, which was originally released in September 2015. Compare this to the long-term support policies of Chrome (which supports only the latest version of the browser, and only for six weeks) or Firefox (which provides nine months of support for an ESR release), and I think we compare quite favorably. (A stable WebKit series like 2.14 is only supported for six months, but that’s comparable to Firefox.) Not bad?

by Michael Catanzaro at February 08, 2017 05:56 AM



January 31, 2017

WebKitGTK+ 2.15.4 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.16 series.

What’s new in the WebKitGTK+ 2.15.4 release?

  • Make accelerating compositing mode on-demand again. By default it will only be used for websites that require it, saving a lot of memory on websites that don’t need it.
  • Add API to manage hardware acceleration policy.
  • Enable CSS Grid Layout by default.
  • Add API to create ephemeral WebViews to replace the legacy private browsing setting that is now deprecated.
  • Handle HTTP authentication for downloads having a WebView associated.
  • Add API to WebKitWebsiteDataManager to handle websites data.
  • Fix BadDamage X errors happening when resizing the WebView.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

January 31, 2017 12:00 AM



January 20, 2017

WebKitGTK+ 2.15.3 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.16 series.

What’s new in the WebKitGTK+ 2.15.3 release?

  • Add API to set network proxy settings.
  • Add API to set initial notification permissions.
  • Add WebKitSecurityOrigin to the API.
  • Add tag property to WebKitNotification.
  • Create GLX OpenGL contexts using version 3.2 (core profile) when available to reduce the memory consumption on Mesa based drivers.
  • Improve memory pressure handler to reduce the CPU usage on memory pressure situations.
  • Add support for key and code properties on keyboard events.
  • More user agent string improvements to improve compatibility with several websites.
  • Fix network process crashes when loading custom URI schemes.
  • Fix web process crash when closing the web view in X11.
  • Fix several crashes and rendering issues.
  • Translation updates: German.

Thanks to all the contributors who made possible this release.

January 20, 2017 12:00 AM



January 17, 2017

WebKitGTK+ Security Advisory WSA-2017-0001

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+.

  • CVE-2016-4692
    • Versions affected: WebKitGTK+ before 2.14.1.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved memory handling.
  • CVE-2016-4743
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Alan Cutter.
    • Impact: Processing maliciously crafted web content may result in the disclosure of process memory. Description: A memory corruption issue was addressed through improved input validation.
  • CVE-2016-7586
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Boris Zbarsky.
    • Impact: Processing maliciously crafted web content may result in the disclosure of user information. Description: A validation issue was addressed through improved state management.
  • CVE-2016-7587
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Adam Klein.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7589
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A memory corruption issue was addressed through improved state management.
  • CVE-2016-7592
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to xisigr of Tencent’s Xuanwu Lab (tencent.com).
    • Impact: Processing maliciously crafted web content may compromise user information. Description: An issue existed in handling of JavaScript prompts. This was addressed through improved state management.
  • CVE-2016-7598
    • Versions affected: WebKitGTK+ before 2.14.0.
    • Credit to Samuel Groß.
    • Impact: Processing maliciously crafted web content may result in the disclosure of process memory. Description: An uninitialized memory access issue was addressed through improved memory initialization.
  • CVE-2016-7599
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Muneaki Nishimura (nishimunea) of Recruit Technologies Co., Ltd.
    • Impact: Processing maliciously crafted web content may result in the disclosure of user information. Description: An issue existed in the handling of HTTP redirects. This issue was addressed through improved cross origin validation.
  • CVE-2016-7610
    • Versions affected: WebKitGTK+ before 2.14.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. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7611
    • Versions affected: WebKitGTK+ before 2.14.2.
    • 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 through improved state management.
  • CVE-2016-7623
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to xisigr of Tencent’s Xuanwu Lab (tencent.com).
    • Impact: Visiting a maliciously crafted website may compromise user information. Description: An issue existed in the handling of blob URLs. This issue was addressed through improved URL handling.
  • CVE-2016-7632
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Jeonghoon Shin.
    • Impact: Visiting a maliciously crafted webpage may lead to an unexpected application termination or arbitrary code execution. Description: A memory corruption issue was addressed through improved state management.
  • CVE-2016-7635
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved memory handling.
  • CVE-2016-7639
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Tongbo Luo of Palo Alto Networks.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7640
    • Versions affected: WebKitGTK+ before 2.14.2.
    • Credit to Kai Kang 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 through improved state management.
  • CVE-2016-7641
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Kai Kang 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 through improved state management.
  • CVE-2016-7642
    • Versions affected: WebKitGTK+ before 2.14.2.
    • Credit to Tongbo Luo of Palo Alto Networks.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved state management.
  • CVE-2016-7645
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Kai Kang 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 through improved state management.
  • CVE-2016-7646
    • Versions affected: WebKitGTK+ before 2.14.2.
    • Credit to Kai Kang 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 through improved state management.
  • CVE-2016-7648
    • Versions affected: WebKitGTK+ before 2.14.2.
    • Credit to Kai Kang 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 through improved state management.
  • CVE-2016-7649
    • Versions affected: WebKitGTK+ before 2.14.2.
    • Credit to Kai Kang 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 through improved state management.
  • CVE-2016-7652
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Apple.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: Multiple memory corruption issues were addressed through improved memory handling.
  • CVE-2016-7654
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Keen 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 through improved state management.
  • CVE-2016-7656
    • Versions affected: WebKitGTK+ before 2.14.3.
    • Credit to Keen Lab working with Trend Micro’s Zero Day Initiative.
    • Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Description: A memory corruption 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

January 17, 2017 12:00 AM



WebKitGTK+ 2.14.3 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.3 release?

  • Create GLX OpenGL contexts using version 3.2 (core profile) when available to reduce the memory consumption on Mesa based drivers.
  • Improve memory pressure handler to reduce the CPU usage on memory pressure situations.
  • Fix a regression in WebKitWebView title notify signal emission that caused the signal to be emitted multiple times.
  • Fix high CPU usage in the web process loading hyphenation dictionaries.
  • More user agent string improvements to improve compatibility with several websites.
  • Fix web process crash when closing the web view in X11.
  • Fix the build with OpenGL ES2 enabled.
  • Fix several crashes and rendering issues.
  • Translation updates: German.
  • Security fixes: CVE-2016-7656, CVE-2016-7635, CVE-2016-7654, CVE-2016-7639, CVE-2016-7645, CVE-2016-7652, CVE-2016-7641, CVE-2016-7632, CVE-2016-7599, CVE-2016-7592, CVE-2016-7589, CVE-2016-7623, CVE-2016-7586.

Thanks to all the contributors who made possible this release.

January 17, 2017 12:00 AM



December 15, 2016

Thu 2016/Dec/15

by Claudio Saavedra

Igalia is hiring. We're currently interested in Multimedia and Chromium developers. Check the announcements for details on the positions and our company.

December 15, 2016 05:13 PM



November 21, 2016

A tale of cylinders and shadows

by Gustavo Noronha

Like I wrote before, we at Collabora have been working on improving WebKitGTK+ performance for customer projects, such as Apertis. We took the opportunity brought by recent improvements to WebKitGTK+ and GTK+ itself to make the final leg of drawing contents to screen as efficient as possible. And then we went on investigating why so much CPU was still being used in some of our test cases.

The first weird thing we noticed is performance was actually degraded on Wayland compared to running under X11. After some investigation we found a lot of time was being spent inside GTK+, painting the window’s background.

Here’s the thing: the problem only showed under Wayland because in that case GTK+ is responsible for painting the window decorations, whereas in the X11 case the window manager does it. That means all of that expensive blurring and rendering of shadows fell on GTK+’s lap.

During the web engines hackfest, a couple of months ago, I delved deeper into the problem and noticed, with Carlos Garcia’s help, that it was even worse when HiDPI displays were thrown into the mix. The scaling made things unbearably slower.

You might also be wondering why would painting of window decorations be such a problem, anyway? They should only be repainted when a window changes size or state anyway, which should be pretty rare, right? Right, that is one of the reasons why we had to make it fast, though: the resizing experience was pretty terrible. But we’ll get back to that later.

So I dug into that, made a few tries at understanding the issue and came up with a patch showing how applying the blur was being way too expensive. After a bit of discussion with our own Pekka Paalanen and Benjamin Otte we found the root cause: a fast path was not being hit by pixman due to the difference in scale factors on the shadow mask and the target surface. We made the shadow mask scale the same as the surface’s and voilà, sane performance.

I keep talking about this being a performance problem, but how bad was it? In the following video you can see how huge the impact in performance of this problem was on my very recent laptop with a HiDPI display. The video starts with an Epiphany window running with a patched GTK+ showing a nice demo the WebKit folks cooked for CSS animations and 3D transforms.

After a few seconds I quickly alt-tab to the version running with unpatched GTK+ – I made the window the exact size and position of the other one, so that it is under the same conditions and the difference can be seen more easily. It is massive.

Yes, all of that slow down was caused by repainting window shadows! OK, so that solved the problem for HiDPI displays, made resizing saner, great! But why is GTK+ repainting the window even if only the contents are changing, anyway? Well, that turned out to be an off-by-one bug in the code that checks whether the invalidated area includes part of the window decorations.

If the area being changed spanned the whole window width, say, it would always cause the shadows to be repainted. By fixing that, we now avoid all of the shadow drawing code when we are running full-window animations such as the CSS poster circle or gtk3-demo’s pixbufs demo.

As you can see in the video below, the gtk3-demo running with the patched GTK+ (the one on the right) is using a lot less CPU and has smoother animation than the one running with the unpatched GTK+ (left).

Pretty much all of the overhead caused by window decorations is gone in the patched version. It is still using quite a bit of CPU to animate those pixbufs, though, so some work still remains. Also, the overhead added to integrate cairo and GL rendering in GTK+ is pretty significant in the WebKitGTK+ CSS animation case. Hopefully that’ll get much better from GTK+ 4 onwards.

by kov at November 21, 2016 05:04 PM



WebKitGTK+ 2.15.2 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.16 series.

What’s new in the WebKitGTK+ 2.15.2 release?

  • Add new API to notify about dynamically added forms to Web Extensions.
  • Implement selection interface and states for elements supporting aria-selected and for menu roles.
  • Expose STATE_SINGLE_LINE and STATE_MULTI_LINE for ARIA searchbox role.
  • Enable WebMemorySampler.
  • Downloads started by context menu actions now have a web view associated.
  • Fix a network process crash when main resource load is converted into a download.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

November 21, 2016 12:00 AM



November 10, 2016

Web Engines Hackfest 2016

by Xabier Rodríguez Calvar

From September 26th to 28th we celebrated at the Igalia HQ the 2016 edition of the Web Engines Hackfest. This year we broke all records and got participants from the three main companies behind the three biggest open source web engines, say Mozilla, Google and Apple. Or course, it was not only them, we had some other companies and ourselves. I was active part of the organization and I think we not only did not get any complain but people were comfortable and happy around.

We had several talks (I included the slides and YouTube links):

We had lots and lots of interesting hacking and we also had several breakout sessions:

  • WebKitGTK+ / Epiphany
  • Servo
  • WPE / WebKit for Wayland
  • Layout Models (Grid, Flexbox)
  • WebRTC
  • JavaScript Engines
  • MathML
  • Graphics in WebKit

What I did during the hackfest was working with Enrique and Žan to advance on reviewing our downstream implementation of our GStreamer based of Media Source Extensions (MSE) in order to land it as soon as possible and I can proudly say that we did already (we didn’t finish at the hackfest but managed to do it after it). We broke the bots and pissed off Michael and Carlos but we managed to deactivate it by default and continue working on it upstream.

So summing up, from my point of view and it is not only because I was part of the organization at Igalia, based also in other people’s opinions, I think the hackfest was a success and I think we will continue as we were or maybe growing a bit (no spoilers!).

Finally I would like to thank our gold sponsors Collabora and Igalia and our silver sponsor Mozilla.

by calvaris at November 10, 2016 08:59 AM