October 04, 2019

WebKitGTK 2.27.1 released!

by The WebKitGTK Project

This is the first development release leading toward 2.28 series.

What’s new in the WebKitGTK 2.27.1 release?

  • Enable async scrolling when accelerating compositing policy is ‘always’.
  • Add about:gpu to show information about the graphics stack.
  • Add API to enable Process Swap on (Cross-site) Navigation, that is now disabled by default.
  • Add WebKitWebView:page-id property.
  • Improve swipe navigation gesture style.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

October 04, 2019 12:00 AM



September 23, 2019

WebKitGTK 2.26.1 released!

by The WebKitGTK Project

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

What’s new in the WebKitGTK 2.26.1 release?

  • Fix MSE media player with GStreamer 1.14.
  • Fix HTML alternate loads never finishing.
  • Fix web view initialization delay on fisrt load.
  • Validate user agent string set via API.
  • Fix a crash when a web view is destroyed with accelerated compositing mode enabled.
  • Fix EGL initialization with newer versions of Mesa.
  • Do not enable the sandbox inside docker.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

September 23, 2019 12:00 AM



September 18, 2019

Epiphany Technology Preview Users: Action Required

by Michael Catanzaro

Epiphany Technology Preview has moved from https://sdk.gnome.org to https://nightly.gnome.org. The old Epiphany Technology Preview is now end-of-life. Action is required to update. If you installed Epiphany Technology Preview prior to a couple minutes ago, uninstall it using GNOME Software and then reinstall using this new flatpakref.

Apologies for this disruption.

The main benefit to end users is that you’ll no longer need separate remotes for nightly runtimes and nightly applications, because everything is now hosted in one repo. See Abderrahim’s announcement for full details on why this transition is occurring.

by Michael Catanzaro at September 18, 2019 02:19 PM



September 09, 2019

WebKitGTK 2.26.0 released!

by The WebKitGTK Project

This is the first stable release in the 2.26 series.

Highlights of the WebKitGTK 2.26.0 release

  • Add support for subprocess sandboxing.
  • Add support for HSTS (HTTP Strict Transport Security).
  • Use libwpe with fdo backend to implement accelerated compositing under wayland.
  • Remove support for GTK2 NPAPI plugins.
  • Add support for datalist element in text input fields.
  • Show the emoji chooser popover for editable content.
  • Improve rendering of form controls when GTK theme is dark.
  • Fix rendering artifacts in youtube volume button and github comment box.
  • Single process model has been deprecated for security reasons.

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

Thanks to all the contributors who made possible this release.

September 09, 2019 12:00 AM



September 08, 2019

WebKit Vulnerabilities Facilitate Human Rights Abuses

by Michael Catanzaro

Chinese state actors have recently abused vulnerabilities in the JavaScriptCore component of WebKit to hack the personal computing devices of Uighur Muslims in the Xinjiang region of China. Mass digital surveillance is a key component of China’s ongoing brutal human rights crackdown in the region.

This has resulted in a public relations drama that is largely a distraction to the issue at hand. Whatever big-company PR departments have to say on the matter, I have no doubt that the developers working on WebKit recognize the severity of this incident and are grateful to Project Zero, which reported these vulnerabilities and has previously provided numerous other high-quality private vulnerability reports. (Many other organizations deserve credit for similar reports, especially Trend Micro’s Zero Day Initiative.)

WebKit as a project will need to reassess certain software development practices that may have facilitated the abuse of these vulnerabilities. The practice of committing security fixes to open source long in advance of corresponding Safari releases may need to be reconsidered.

Sadly, Uighurs should assume their personal computing devices have been compromised by state-sponsored attackers, and that their private communications are not private. Even if not compromised in this particular incident, similar successful attacks are overwhelmingly likely in the future.

by Michael Catanzaro at September 08, 2019 05:32 PM



September 03, 2019

WebKitGTK 2.25.92 released!

by The WebKitGTK Project

This is a development release leading toward 2.26 series.

What’s new in the WebKitGTK 2.25.92 release?

  • Add WEBKIT_USE_SINGLE_WEB_PROCESS environment variable to force single process model in all WebKitWebContext. This is a temporary solution for applications still depending on the single process mode behavior. It will be only available in 2.26 series.
  • Add new API to remove a filter from an user content manager given its identifier.
  • Add support for HSTS.
  • Several improvements and bug fixes in MSE media player.
  • Fix building without unified sources.
  • Fix several crashes and rendering issues.
  • Translation updates: Polish, Ukrainian.

Thanks to all the contributors who made possible this release.

September 03, 2019 12:00 AM



August 29, 2019

WebKitGTK and WPE WebKit Security Advisory WSA-2019-0004

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2019-8644
    • Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before 2.24.3.
    • Credit to G. Geshev working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8649
    • Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before 2.24.3.
    • Credit to Sergei Glazunov of Google Project Zero.
    • Processing maliciously crafted web content may lead to universal cross site scripting. A logic issue existed in the handling of synchronous page loads. This issue was addressed with improved state management.
  • CVE-2019-8658
    • Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before 2.24.3.
    • Credit to akayn working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to universal cross site scripting. A logic issue was addressed with improved state management.
  • CVE-2019-8666
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
    • Credit to Zongming Wang (王宗明) and Zhe Jin (金哲) from Chengdu Security Response Center of Qihoo 360 Technology Co. Ltd.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8669
    • Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before 2.24.3.
    • Credit to akayn working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8671
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
    • Credit to Apple.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8672
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
    • Credit to Samuel Groß of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8673
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
    • Credit to Soyeon Park and Wen Xu of SSLab at Georgia Tech.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8676
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
    • Credit to Soyeon Park and Wen Xu of SSLab at Georgia Tech.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8677
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
    • Credit to Jihui Lu of Tencent KeenLab.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8678
    • Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before 2.24.3.
    • Credit to an anonymous researcher, Anthony Lai (@darkfloyd1014) of Knownsec, Ken Wong (@wwkenwong) of VXRL, Jeonghoon Shin (@singi21a) of Theori, Johnny Yu (@straight_blast) of VX Browser Exploitation Group, Chris Chan (@dr4g0nfl4me) of VX Browser Exploitation Group, Phil Mok (@shadyhamsters) of VX Browser Exploitation Group, Alan Ho (@alan_h0) of Knownsec, Byron Wai of VX Browser Exploitation.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8679
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
    • Credit to Jihui Lu of Tencent KeenLab.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8680
    • Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before 2.24.3.
    • Credit to Jihui Lu of Tencent KeenLab.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8681
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
    • Credit to G. Geshev working with Trend Micro Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8683
    • Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before 2.24.3.
    • Credit to lokihardt of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8684
    • Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before 2.24.3.
    • Credit to lokihardt of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8686
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
    • Credit to G. Geshev working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8687
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
    • Credit to Apple.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8688
    • Versions affected: WebKitGTK before 2.24.4 and WPE WebKit before 2.24.3.
    • Credit to Insu Yun of SSLab at Georgia Tech.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8689
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
    • Credit to lokihardt of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8690
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.3.
    • Credit to Sergei Glazunov of Google Project Zero.
    • Processing maliciously crafted web content may lead to universal cross site scripting. A logic issue existed in the handling of document loads. This issue was addressed with improved state management.

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

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

August 29, 2019 12:00 AM



August 28, 2019

WebKitGTK 2.24.4 released!

by The WebKitGTK Project

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

What’s new in the WebKitGTK 2.24.4 release?

  • Updated the user agent string to make happy certain websites which would claim that the browser being used was unsupported.
  • Improve loading of multimedia streams to avoid memory exhaustion due to excessive caching.
  • Fix display of documents with MIME type application/xml in the Web Inspector, when loaded using XmlHttpRequest.
  • Fix a hang while scrolling certain websites which include HLS video content (Twitter, for example).
  • Fix rounding artifacts in volume levels for media playback.
  • Fix several crashes and rendering issues.
  • Fix the build with video track support disabled.
  • Fix the build with OpenGL support disabled.
  • Fix build issue which would cause media controls to disappear when Python 3.x was used during the build process.

Thanks to all the contributors who made possible this release.

August 28, 2019 12:00 AM



August 05, 2019

Review of the Igalia Multimedia team Activities (2019/H1)

by Philippe Normand

This blog post takes a look back at the various Multimedia-related tasks the Igalia Multimedia team was involved in during the first half of 2019.

GStreamer Editing Services

Thibault added support for the OpenTimelineIO open format for editorial timeline information. Having many editorial timeline information formats supported by OpenTimelineIO reduces …

by Philippe Normand at August 05, 2019 01:30 PM



August 02, 2019

WebKitGTK 2.25.4 released!

by The WebKitGTK Project

This is a development release leading toward 2.26 series.

What’s new in the WebKitGTK 2.25.4 release?

  • Switch to use libsoup WebSockets API.
  • Add support for permessage-deflate WebSocket extension.
  • Add support for datalist element in text input fields.
  • Fix a crash with empty video source.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

August 02, 2019 12:00 AM



July 23, 2019

WebKitGTK 2.25.3 released!

by The WebKitGTK Project

This is a development release leading toward 2.26 series.

What’s new in the WebKitGTK 2.25.3 release?

  • Remove support for GTK2 NPAPI plugins.
  • Fix web view updates after swapping web process if accelerated compositing mode is forced.
  • Make kinetic scrolling work again.
  • Fix position of emoji chooser when page is scrolled.
  • Fix web process deadlock when scrolling twitter timeline which contains HLS videos.
  • Make navigation gesture use dark fallback background color color on dark themes.
  • Make Previous/Next gesture work in RTL mode.
  • Support cancelling touchscreen back/forward gesture.
  • Add user agent quirk to make github work in FreeBSD.
  • Fix content disappearing when using CSS transforms.
  • Fix some radio streams that could not be played.
  • Fix video pause that sometimes caused to skip to finish.
  • Fix volume level changes when playing a video.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

July 23, 2019 12:00 AM



July 02, 2019

WebKitGTK 2.24.3 released!

by The WebKitGTK Project

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

What’s new in the WebKitGTK 2.24.3 release?

  • Deprecate WebSQL APIs.
  • Make Previous/Next gesture work in RTL mode.
  • Fix content disappearing when using CSS transforms.
  • Fix rendering artifacts in youtube volume button.
  • Fix trapezoid artifact in github comment box.
  • Fix video pause that sometimes caused to skip to finish.
  • Fix volume level changes when playing a video.
  • Fix HLS streams being slow to start.
  • Fix some radio streams that could not be played.
  • Fix the build with older versions of GStreamer.
  • Fix the build with video and audio disabled.
  • Fix several crashes and rendering issues.
  • Translation updates: Brazilian Portuguese.

Thanks to all the contributors who made possible this release.

July 02, 2019 12:00 AM



June 28, 2019

On Version Numbers

by Michael Catanzaro

I’m excited to announce that Epiphany Tech Preview has reached version 3.33.3-33, as computed by git describe. That is 33 commits after 3.33.3:

Epiphany about dialog displaying the version number

I’m afraid 3.33.4 will arrive long before we  make it to 3.33.3-333, so this is probably the last cool version number Epiphany will ever have.

I might be guilty of using an empty commit to claim the -33 commit.

I might also apologize for wasting your time with a useless blog post, except this was rather fun. I await the controversy of your choice in the comments.

by Michael Catanzaro at June 28, 2019 04:07 PM



June 17, 2019

WebKitGTK 2.25.2 released!

by The WebKitGTK Project

This is a development release leading toward 2.26 series.

What’s new in the WebKitGTK 2.25.2 release?

  • Enable process switch on cross site navigation.
  • Use libwpe with fdo backend to implement accelerated compositing under wayland.
  • Fix rendering artifacts in youtube volume button.
  • Fix trapezoid artifact in github comment box.
  • Ensure web extensions directory is readable when sandbox is enabled.
  • Fix the executable name of WebDriver process, renamed by mistake in 2.25.1.
  • Enable hyperlink auditing setting by default.
  • Remove the option to build without using the redirected XComposite window.
  • Fix HLS streams being slow to start.
  • Make accessibility work when sandbox is enabled.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

June 17, 2019 12:00 AM



June 14, 2019

An OpenJPEG Surprise

by Michael Catanzaro

My previous blog post seems to have resolved most concerns about my requests for Ubuntu stable release updates, but I again received rather a lot of criticism for the choice to make WebKit depend on OpenJPEG, even though my previous post explained clearly why there are are not any good alternatives.

I was surprised to receive a pointer to ffmpeg, which has its own JPEG 2000 decoder that I did not know about. However, we can immediately dismiss this option due to legal problems with depending on ffmpeg. I also received a pointer to a resurrected libjasper, which is interesting, but since libjasper was removed from Ubuntu, its status is not currently better than OpenJPEG.

But there is some good news! I have looked through Ubuntu’s security review of the OpenJPEG code and found some surprising results. Half the reported issues affect the library’s companion tools, not the library itself. And the other half of the issues affect the libmj2 library, a component of OpenJPEG that is not built by Ubuntu and not used by WebKit. So while these are real security issues that raise concerns about the quality of the OpenJPEG codebase, none of them actually affect OpenJPEG as used by WebKit. Yay!

The remaining concern is that huge input sizes might cause problems within the library that we don’t yet know about. We don’t know because OpenJPEG’s fuzzer discards huge images instead of testing them. Ubuntu’s security team thinks there’s a good chance that fixing the fuzzer could uncover currently-unknown multiplication overflow issues, for instance, a class of vulnerability that OpenJPEG has clearly had trouble with in the past. It would be good to see improvement on this front. I don’t think this qualifies as a security vulnerability, but it is certainly a security problem that would facilitate discovering currently-unknown vulnerabilities if fixed.

Still, on the whole, the situation is not anywhere near as bad as I’d thought. Let’s hope OpenJPEG can be included in Ubuntu main sooner rather than later!

by Michael Catanzaro at June 14, 2019 02:43 PM



June 10, 2019

A new terminal-style line breaking with CSS Text

by Javier Fernández

The CSS Text 3 specification defines a module for text manipulation and covers, among a few other features, the line breaking behavior of the browser, including white space handling. I’ve been working lately on some new features and bug fixing for this specification and I’d like to introduce in this posts the last one we made available for the Web Platform users. This is yet another contribution that came out the collaboration between Igalia and Bloomberg, which has been held for several years now and has produced many important new features for the Web, like CSS Grid Layout.

The feature

I guess everybody knows the white-space CSS property, which allows web authors to control two main aspects of the rendering of a text line: collapsing and wrapping. A new value break-spaces has been added to the ones available for this property, which allows web authors to emulate a terminal-like line breaking behavior. This new value operates basically like pre-wrap, but with two key differences:

  • any sequence of preserved white space characters takes up space, even at the end of the line.
  • a preserved white space sequence can be wrapped at any character, moving the rest of the sequence, intact, to the line bellow.

What does this new behavior actually mean ? I’ll try to explain it with a few examples. Lets start with a simple but quite illustrative demo which tries to emulate a meteorology monitoring system which shows relevant changes over time, where the gaps between subsequent changes must be preserved:




    

Another interesting use case for this feature could be a logging system which should preserve the text formatting of the logged information, considering different window sizes. The following demo tries to describe this such scenario:



Hash: 5a2a3d23f88174970ed8 Version: webpack 3.12.0 Time: 22209ms Asset Size Chunks Chunk Names pages/widgets/index.51838abe9967a9e0b5ff.js 1.17 kB 10 [emitted] pages/widgets/index img/icomoon.7f1da5a.svg 5.38 kB [emitted] fonts/icomoon.2d429d6.ttf 2.41 kB [emitted] img/fontawesome-webfont.912ec66.svg 444 kB [emitted] [big] fonts/fontawesome-webfont.b06871f.ttf 166 kB [emitted] img/mobile.8891a7c.png 39.6 kB [emitted] img/play_button.6b15900.png 14.8 kB [emitted] img/keyword-back.f95e10a.jpg 43.4 kB [emitted] . . .

Use cases

In the demo shown before there are several cases that I think it’s worth to analyze in detail.

A breaking opportunity exists after any white space character

The main purpose of this feature is to preserve the white space sequences length even when it has to be wrapped into multiple lines. The following example tries to describe this basic use case:



XX XX

The example above shows how the white space sequence with a length of 15 characters is preserved and wrapped along 3 different lines.

Single leading white space

Before the addition of the break-spaces value this scenario was only possible at the beginning of the line. In any other case, the trailing white spaces were either collapsed or hang, hence the next line couldn’t start with a sequence of white spaces. Lets consider the following example:



XX XX

Like when using pre-wrap, the single leading space is preserved. Since break-spaces allows breaking opportunities after any white space character, we break after the first leading white space (” |XX XX”). The second line can be broken after the first preserved white space, creating another leading white space in the next line (” |XX | XX”).

However, lets consider now a case without such first single leading white space.



XXX XX

Again, it s not allowed to break before the first space, but in this case there isn’t any previous breaking opportunity, so the first space after the word XX should overflow (“XXX | XX”); the next white space character will be moved down to the next line as preserved leading space.

Breaking before the first white space

I mentioned before that the spec states clearly that the break-space feature allows breaking opportunities only after white space characters. However, it’d be possible to break the line just before the first white space character after a word if the feature is used in combination with other line breaking CSS properties, like word-break or overflow-wrap (and other properties too).



XXXX X

The two white spaces between the words are preserved due to the break-spaces feature, but the first space after the XXXX word would overflow. Hence, the overflow-wrap: break-word feature is applied to prevent the line to overflow and introduce an additional breaking opportunity just before the first space after the word. This behavior causes that the trailing spaces are moved down as a leading white space sequence in the next line.

We would get the same rendering if word-break: break-all is used instead overflow-wrap (or even in combination), but this is actualy an incorrect behavior, which has the corresponding bug reports in WebKit (197277) and Blink (952254) according to the discussion in the CSS WG (see issue #3701).

Consider previous breaking opportunities

In the previous example I described a combination of line breaking features that would allow breaking before the first space after a word. However, this should be avoided if there are previous breaking opportunities. The following example is one of the possible scenarios where this may happen:



XX X X

In this case, we could break after the second word (“XX X| X”), since overflow-wrap: break-word would allow us to do that in order to avoid the line to overflow due to the following white space. However, white-space: break-spaces only allows breaking opportunities after a space character, hence, we shouldn’t break before if there are valid previous opportunities, like in this case in the space after the first word (“XX |X X”).

This preference for previous breaking opportunities before breaking the word, honoring the overflow-wrap property, is also part of the behavior defined for the white-space: pre-wrap feature; although in that case, there is no need to deal with the issue of breaking before the first space after a word since trailing space will just hang. The following example uses just the pre-wrap to show how previous opportunities are selected to avoid overflow or breaking a word (unless explicitly requested by word-break property).



XX
overflow-wrap:
break-word
word-break:
break-all

In this case, break-all enables breaking opportunities that are not available otherwise (we can break a word at any letter), which can be used to prevent the line to overflow; hence, the overflow-wrap property doesn’t take any effect. The existence of previous opportunities is not considered now, since break-all mandates to produce the longer line as possible.

This new white-space: break-spaces feature implies a different behavior when used in combination with break-all. Even though the preference of previous opportunities should be ignored if we use the word-break: break-all, this may not be the case for the breaking before the first space after a word scenario. Lets consider the same example but using now the word-break: break-all feature:



XX X X

The example above shows that using word-break: break-all doesn’t produce any effect. It’s debatable whether the use of break-all should force the selection of the breaking opportunity that produces the longest line, like it happened in the pre-wrap case described before. However, the spec states clearly that break-spaces should only allow breaking opportunities after white space characters. Hence, I considered that breaking before the first space should only happen if there is no other choice.

As a matter of fact, specifying break-all we shouldn’t considering only previous white spaces, to avoid breaking before the first white space after a word; the break-all feature creates additional breaking opportunities, indeed, since it allows to break the word at any character. Since break-all is intended to produce the longest line as possible, this new breaking opportunity should be chosen over any previous white space. See the following test case to get a clearer idea of this scenario:



X XX X

Bear in mind that the expected rendering in the above example may not be obtained if your browser’s version is still affected by the bugs 197277(Safari/WebKit) and 952254(Chrome/Blink). In this case, the word is broken despite the opportunity in the previous white space, and also avoiding breaking after the ‘XX’ word, just before the white space.

There is an exception to the rule of avoiding breaking before the first white space after a word if there are previous opportunities, and it’s precisely the behavior the line-break: anywhere feature would provide. As I said, all these assumptions were not, in my opinion, clearly defined in the current spec, so that’s why I filed an issue for the CSS WG so that we can clarify when it’s allowed to break before the first space.

Current status and support

The intent-to-ship request for Chrome has been approved recently, so I’m confident the feature will be enabled by default in Chrome 76. However, it’s possible to try the feature in older versions by enabling the Experimental Web Platform Features flag. More details in the corresponding Chrome Status entry. I want to highlight that I also implemented the feature for LayoutNG, the new layout engine that Chrome will eventually ship; this achievement is very important to ensure the stability of the feature in future versions of Chrome.

In the case of Safari, the patch with the implementation of the feature landed in the WebKit’s trunk in r244036, but since Apple doesn’t announce publicly when a new release of Safari will happen or which features it’ll ship, it’s hard to guess when the break-spaces feature will be available for the web authors using such browser. Meanwhile, It’s possible to try the feature in the Safari Technology Preview 80.

Finally, while I haven’t see any signal of active development in Firefox, some of the Mozilla developers working on this area of the Gecko engine have shown public support for the feature.

The following table summarizes the support of the break-spaces feature in the 3 main browsers:

Chrome Safari Firefox
Experimental M73 STP 80 Public support
Ship M76 Unknown Unknown

Web Platform Tests

At Igalia we believe that the Web Platform Tests project is a key piece to ensure the compatibility and interoperability of any development on the Web Platform. That’s why a substantial part of my work to implement this relatively small feature was the definition of enough tests to cover the new functionality and basic use cases of the feature.

white-space overflow-wrap word-break
pre-wrap-008
pre-wrap-015
pre-wrap-016
break-spaces-003
break-spaces-004
break-spaces-005
break-spaces-006
break-spaces-007
break-spaces-008
break-spaces-009
break-word-004
break-word-005
break-word-006
break-word-007
break-word-008
break-all-010
break-all-011
break-all-012
break-all-013
break-all-014
break-all-015

Implementation in several web engines

During the implementation of a browser feature, even a small one like this, it’s quite usual to find out bugs and interoperability issues. Even though this may slow down the implementation of the feature, it’s also a source of additional Web Platform tests and it may contribute to the robustness of the feature itself and the related CSS properties and values. That’s why I decided to implement the feature in parallel for WebKit (Safari) and Blink (Chrome) engines, which I think it helped to ensure interoperability and code maturity. This approach also helped to get a deeper understanding of the line breaking logic and its design and implementation in different web engines.

I think it’s worth mentioning some of these code architectural differences, to get a better understanding of the work and challenges this feature required until it reached web author’s browser.

Chrome/Blink engine

Lets start with Chrome/Blink, which was especially challenging due to the fact that Blink is implementing a new layout engine (LayoutNG). The implementation for the legacy layout engine was the first step, since it ensures the feature will arrive earlier, even behind an experimental runtime flag.

The legacy layout relies on the BreakingContext class to implement the line breaking logic for the inline layout operations. It has the main characteristic of handling the white space breaking opportunities by its own, instead of using the TextBreakIterator (based on ICU libraries), as it does for determining breaking opportunities between letters and/or symbols. This design implies too much complexity to do even small changes like this, especially because is very sensible in terms of performance impact. In the following diagram I try to show a simplified view of the classes involved and the interactions implemented by this line breaking logic.

The LayoutNG line breaking logic is based on a new concept of fragments, mainly handled by the NGLineBreaker class. This new design simplifies the line breaking logic considerably and it’s highly optimized and adapted to get the most of the TextBreakIterator classes and the ICU features. I tried to show a simplified view of this new design with the following diagram:

In order to describe the work done to implement the feature for this web engine, I’ll list the main bugs and patches landed during this time: CR#956465, CR#952254, CR#944063,CR#900727, CR#767634, CR#922437

Safari/WebKit engine

Although as time passes this is less probable, WebKit and Blink still share some of the layout logic from the ages prior to the fork. Although Blink engineers have applied important changes to the inline layout logic, both code refactoring and optimizations, there are common design patterns that made relatively easy porting to WebKit the patches that implemented the feature for the Blink’s legacy layout. In WebKit, the line breaking logic is also implemented by the BreakingContext class and it has a similar architecture, as it’s described, in a quite simplified way, in the class diagram above (it uses different class names for the render/layout objects, though) .

However, Safari supports for the mac and iOS platforms a different code path for the line breaking logic, implemented in the SimpleLineLayout class. This class provides a different design for the line breaking logic, and, similar to what Blink implements in LayoutNG, is based on a concept of text fragments. It also relies as much as possible into the TextBreakIterator, instead of implementing complex rules to handle white spaces and breaking opportunities. The following diagrams show this alternate design to implement the line breaking process.

This SimpleLineLayout code path in not supported by other WebKit ports (like WebKitGtk+ or WPE) and it’s not available either when using some CSS Text features or specific fonts. There are other limitations to use this SimpleLineLayout codepath, which may lead to render the text using the BreakingContext class.

Again, this is the list of bugs that were solved to implement the feature for the WebKit engine: WK#197277, WK#196169, WK#196353, WK#195361, WK#177327, WK#197278

Conclusion

I hope that at this point these 2 facts are clear now:

  • The white-space: break-spaces feature is a very simple but powerful feature that provides a new line breaking behavior, based on unix-terminal systems.
  • Although it’s a simple feature, on the paper (spec), it implies a considerable amount of work so that it reaches the browser and it’s available for web authors.

In this post I tried to explain in a simple way the main purpose of this new feature and also some interesting corner cases and combinations with other Line Breaking features. The demos I used shown 2 different use cases of this feature, but there are may more. I’m sure the creativity of web authors will push the feature to the limits; by then, I’ll be happy to answer doubts, about the spec or the implementation for the web engines, and of course fix the bugs that may appear once the feature is more used.

Igalia logo
Bloomberg logo

Igalia and Bloomberg working together to build a better web

Finally, I want to thank Bloomberg for supporting the work to implement this feature. It’s another example of how non-browser vendors can influence the Web Platform and contribute with actual features that will be eventually available for web authors. This is the kind of vision that we need if we want to keep a healthy, open and independent Web Platform.

by jfernandez at June 10, 2019 08:11 PM



May 27, 2019

WebKitGTK 2.25.1 released!

by The WebKitGTK Project

This is the first development release leading toward 2.26 series.

What’s new in the WebKitGTK 2.25.1 release?

  • Add support for subprocess sandboxing.
  • Add API to get the web process unique identifier of a WebKitFrame.
  • Add WebKitWebPage::did-associate-form-controls-for-frame signal and deprecate did-associate-form-controls.
  • Implement AtkComponentIface scroll_to methods.
  • Improve rendering of form controls when GTK theme is dark and enable prefers-color-scheme media query.
  • Show the emoji chooser popover for editable content.
  • Fix touch capabilities detection for websites checking touch events properties present in window or pointer media queries.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

May 27, 2019 12:00 AM



May 24, 2019

Dear Ubuntu: Please Stop Packaging Epiphany If You Won’t Do It Properly

by Michael Catanzaro

Dear Ubuntu,

When users try Epiphany on Ubuntu, they receive a sub-par, broken browser. If you’re not willing to do this right, please just remove Epiphany from your repositories. We’d all be happier this way. You are the  most popular distributor of Epiphany by far, and your poor packaging is making the browser look bad.

Epiphany 3.28.1 Is Stupid Old

Currently you’ve packaged Epiphany 3.28.1 for Ubuntu 18.04, your current LTS release. 3.28.1 is a seriously broken version with an overaggressive adblock filters subscription that blocks legitimate resources on a wide variety of websites, resulting in broken page rendering. We obviously don’t want users to ever use 3.28.1. There is a 3.28.2, released on May 22, 2018, which fixes this problem, but after one year you have still not yet updated. Ideally you would update to 3.28.5, which has been available since September 21, 2018. It’s not like I’m expecting you to upgrade to 3.30 or to 3.32 (the current stable series). I’d be happy to release a 3.28.6, except I know that it’s pointless: you would not upgrade to it if I did.

In Ubuntu 19.04, you have packaged Epiphany 3.32.0. The current version is 3.32.2. There are a lot of bugs fixed in between. (Update: Exam has pointed out that your snap package takes precedence over the Debian package in GNOME Software, so most users will actually receive the snap instead. The snap is still using 3.30.4, because Epiphany 3.32 depends on GTK 3.24, and that is not available in snaps yet. All app menu items are unavailable because Ubuntu’s GNOME Shell 3.32 does not display Epiphany 3.30’s app menu, so there’s no way to edit preferences, view history, import/export bookmarks, etc. This is not good.)

Because Epiphany is in your universe repository, rather than main, I understand that Canonical does not provide updates. But this is really not OK. Do I really need to add an xscreensaver-style time bomb to protect the reputation of Epiphany?

You’ve Disabled the JPEG 2000 Support

WebKitGTK is in main and you have been updating it regularly and in a timely manner, which is good. Thanks for this!

But we also need WebKitGTK to be built with OpenJPEG support, so that it can display JPEG 2000 images. Because you build WebKitGTK without OpenJPEG support, lots of popular websites are broken, including all websites using Akamai Image Manager. Because we have “Safari” but not “Chromium” in our user agent, these websites send us lots of JPEG 2000 images, and we need to be prepared to handle them properly to avoid broken websites. (Changing our user agent to avoid receiving JPEG 2000 images is, unfortunately, not practical.)

Here we have a really difficult issue, because you admittedly have a good reason for disabling OpenJPEG use. OpenJPEG has failed your security review for inclusion in main. Seth Arnold from the Ubuntu Security Team has reported 24 issues in OpenJPEG, of which 21 still remain unfixed. (It’s probably too much to ask, but if any readers want to help tackle a couple of these, that would be really great.) WebKitGTK is only as secure as its least-secure image decoder, and it seems likely that that would be OpenJPEG. Exposing the low-quality OpenJPEG library to the entire web is risky.

And yet, a web browser that doesn’t display websites properly is simply not worth delivering to users. We need this image decoder for web compatibility. WebKitGTK 2.26 will (hopefully) ship with a sandbox to mitigate security risks. Perhaps future versions of Epiphany should refuse to start if OpenJPEG support is unavailable?

by Michael Catanzaro at May 24, 2019 03:28 PM



May 20, 2019

WebKitGTK and WPE WebKit Security Advisory WSA-2019-0003

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2019-6237
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
    • Credit to G. Geshev working with Trend Micro Zero Day Initiative, Liu Long of Qihoo 360 Vulcan Team.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8571
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to 01 working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8583
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to sakura of Tencent Xuanwu Lab, jessica (@babyjess1ca_) of Tencent Keen Lab, and dwfault working at ADLab of Venustech.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8584
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
    • Credit to G. Geshev of MWR Labs working with Trend Micro Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8586
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to an anonymous researcher.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8587
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
    • Credit to G. Geshev working with Trend Micro Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8594
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to Suyoung Lee and Sooel Son of KAIST Web Security & Privacy Lab and HyungSeok Han and Sang Kil Cha of KAIST SoftSec Lab.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8595
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
    • Credit to G. Geshev from MWR Labs working with Trend Micro Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8596
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
    • Credit to Wen Xu of SSLab at Georgia Tech.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8597
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
    • Credit to 01 working with Trend Micro Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8601
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
    • Credit to Fluoroacetate working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8607
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
    • Credit to Junho Jang and Hanul Choi of LINE Security Team.
    • Processing maliciously crafted web content may result in the disclosure of process memory. An out-of-bounds read was addressed with improved input validation.
  • CVE-2019-8608
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
    • Credit to G. Geshev working with Trend Micro Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8609
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to Wen Xu of SSLab, Georgia Tech.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8610
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
    • Credit to Anonymous working with Trend Micro Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8615
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.2.
    • Credit to G. Geshev from MWR Labs working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8611
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to Samuel Groß of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8619
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
    • Credit to Wen Xu of SSLab at Georgia Tech and Hanqing Zhao of Chaitin Security Research Lab.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8622
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to Samuel Groß of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8623
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to Samuel Groß of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.

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

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

May 20, 2019 12:00 AM



May 17, 2019

WebKitGTK 2.24.2 released!

by The WebKitGTK Project

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

What’s new in the WebKitGTK 2.24.2 release?

  • Fix rendering of emojis copy-pasted from GTK emoji chooser.
  • Fix space characters not being rendered with some CJK fonts.
  • Fix adaptive streaming playback with older GStreamer versions.
  • Set a maximum zoom level for pinch zooming gesture.
  • Fix navigation gesture to not interfere with scrolling.
  • Fix SSE2 detection at compile time, ensuring the right flags are passed to the compiler.
  • Fix several crashes and rendering issues.
  • Translation updates: Danish, Spanish, Ukrainian.
  • Security fixes: CVE-2019-8595, CVE-2019-8607, CVE-2019-8615.

Thanks to all the contributors who made possible this release.

May 17, 2019 12:00 AM



April 10, 2019

WebKitGTK and WPE WebKit Security Advisory WSA-2019-0002

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK and WPE WebKit.

  • CVE-2019-6201
    • Versions affected: WebKitGTK before 2.22.6 and WPE WebKit before 2.22.4.
    • Credit to dwfault working with ADLab of Venustech.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-6251
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
    • Credit to Dhiraj.
    • Processing maliciously crafted web content may lead to spoofing. WebKitGTK and WPE WebKit were vulnerable to a URI spoofing attack similar to the CVE-2018-8383 issue in Microsoft Edge.
  • CVE-2019-7285
    • Versions affected: WebKitGTK before 2.22.6 and WPE WebKit before 2.22.4.
    • Credit to dwfault working at ADLab of Venustech.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A use after free issue was addressed with improved memory management.
  • CVE-2019-7292
    • Versions affected: WebKitGTK before 2.22.6 and WPE WebKit before 2.22.4.
    • Credit to Zhunki and Zhiyi Zhang of 360 ESG Codesafe Team.
    • Processing maliciously crafted web content may result in the disclosure of process memory. A validation issue was addressed with improved logic.
  • CVE-2019-8503
    • Versions affected: WebKitGTK before 2.22.6 and WPE WebKit before 2.22.4.
    • Credit to Linus Särud of Detectify.
    • A malicious website may be able to execute scripts in the context of another website. A logic issue was addressed with improved validation.
  • CVE-2019-8506
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to Samuel Groß of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A type confusion issue was addressed with improved memory handling.
  • CVE-2019-8515
    • Versions affected: WebKitGTK before 2.22.6 and WPE WebKit before 2.22.4.
    • Credit to James Lee, @Windowsrcer.
    • Processing maliciously crafted web content may disclose sensitive user information. A cross-origin issue existed with the fetch API. This was addressed with improved input validation.
  • CVE-2019-8518
    • Versions affected: WebKitGTK before 2.22.7 and WPE WebKit before 2.22.5.
    • Credit to Samuel Groß of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8523
    • Versions affected: WebKitGTK before 2.22.7 and WPE WebKit before 2.22.5.
    • Credit to Apple.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8524
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to G. Geshev working with Trend Micro Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8535
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to Zhiyang Zeng, @Wester, of Tencent Blade Team.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved state management.
  • CVE-2019-8536
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to Apple.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2019-8544
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to an anonymous researcher.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2019-8551
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to Ryan Pickren, ryanpickren.com.
    • Processing maliciously crafted web content may lead to universal cross site scripting. A logic issue was addressed with improved validation.
  • CVE-2019-8558
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to Samuel Groß of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8559
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to Apple.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-8563
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.0.
    • Credit to Apple.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-11070
    • Versions affected: WebKitGTK and WPE WebKit before 2.24.1.
    • Credit to Igalia.
    • WebKitGTK and WPE WebKit failed to properly apply configured HTTP proxy settings when downloading livestream video (HLS, DASH, or Smooth Streaming), an error resulting in deanonymization. This issue was corrected by changing the way livestreams are downloaded.

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

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

April 10, 2019 12:00 AM



April 09, 2019

WebKitGTK 2.24.1 released!

by The WebKitGTK Project

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

What’s new in the WebKitGTK 2.24.1 release?

  • Do not allow changes in active URI before provisional load starts for non-API requests.
  • Stop the threaded compositor when the page is not visible or layer tree state is frozen.
  • Use WebKit HTTP source element again for adaptive streaming fragments downloading.
  • Properly handle empty resources in webkit_web_resource_get_data().
  • Add quirk to ensure outlook.live.com uses the modern UI.
  • Fix methods returing GObject or boxed types in JavaScriptCore GLib API.
  • Ensure callback data is passed to functions and constructors with no parameters in JavaScriptCore GLib API.
  • Fix rendering of complex text when the font uses x,y origins.
  • Fix sound loop with Google Hangouts and WhatsApp notifications.
  • Fix the build with GStreamer 1.12.5 and GST GL enabled.
  • Detect SSE2 at compile time.
  • Fix several crashes and rendering issues.
  • Security fixes: CVE-2019-6251.

Thanks to all the contributors who made possible this release.

April 09, 2019 12:00 AM



April 08, 2019

Introducing WPEQt, a WPE API for Qt5

by Philippe Normand

WPEQt provides a QML plugin implementing an API very similar to the QWebView API. This blog post explains the rationale behind this new project aimed for QtWebKit users.

Qt5 already provides multiple WebView APIs, one based on QtWebKit (deprecated) and one based on QWebEngine (aka Chromium). WPEQt aims to provide …

by Philippe Normand at April 08, 2019 10:20 AM



March 27, 2019

Epiphany 3.32 and WebKitGTK 2.24

by Michael Catanzaro

I’m very pleased to (belatedly) announce the release of Epiphany 3.32 and WebKitGTK 2.24. This Epiphany release contains far more changes than usual, while WebKitGTK continues to improve steadily as well. There are a lot of new features to discuss, so let’s dive in.

Dazzling New Address Bar

The most noticeable change is the new address bar, based on libdazzle’s DzlSuggestionEntry. Christian put a lot of effort into designing this search bar to work for both Builder and Epiphany, and Jan-Michael helped integrate it into Epiphany. The result is much nicer than we had before:

The address bar is a central component of the user interface, and this clean design is important to provide a quality user experience. It should also leave a much better first impression than we had before.

Redesigned Tabs Menu

Epiphany 3.24 first added a tab menu at the end of the tab bar. This isn’t very useful if you have only a few tabs open, but if you have a huge number of tabs then it’s useful to help navigate through them. Previously, this menu only showed the page titles of the tabs. For 3.32, Adrien has converted this menu to a nice popover, including favicons, volume indicators, and close buttons. These enhancements were primarily aimed at making the browser easier to use on mobile devices, where there is no tab bar, but they’re nice improvement for desktop users, too.

(On mobile, the tab rows are much larger, to make touch selection easier.)

Touchpad Gestures

Epiphany now supports touchpad gestures. Jan-Michael first added a three-finger swipe to Epiphany, for navigating back and forward. Then Alexander (Exalm) decided to go and rewrite it, pushing the implementation down into WebKit to share as much code as possible with Safari. The end result is a two-finger swipe. This was much more involved than I expected as it required converting a bunch of Apple-specific Objective C++ code into cross-platform C++, but the end result was worth the effort:

Applications that depend on WebKitGTK 2.24 may opt-in to these gestures using webkit_settings_set_enable_back_forward_navigation_gestures().

Alexander also added pinch zoom.

Variable Fonts

Carlos Garcia decided to devote some attention to WebKit’s FreeType font backend, and the result speaks for itself:

Emoji 🦇

WebKit’s FreeType backend has supported emoji for some time, but there were a couple problems:

  • Most emoji combinations were not supported, so while characters like🧟(zombie) would work just fine, characters like 🧟‍♂️(man zombie) and 🧟‍♀️(woman zombie) were broken. Carlos fixed this. (Technically, only emoji combinations using a certain character code were broken, but that was most of them.)
  • There was no code to prefer emoji fonts for rendering emoji, meaning emoji would almost always be displayed in non-ideal fonts, usually DejaVu, resulting in a black and white glyph rather than color. Carlos fixed this, too. This seems to work properly in Firefox on some websites but not others, and it’s currently WONTFIXed in Chrome. It’s good to see WebKit ahead of the game, for once. Note that you’ll see color on this page regardless of your browser, because WordPress replaces the emoji characters with images, but I believe only WebKit can handle the characters themselves. You can test your browser here.

Improved Adaptive Mode

First introduced in 3.30, Adrien has continued to improve adaptive mode to ensure Epiphany works well on mobile devices. 3.32 is the first release to depend on libhandy. Adrien has converted various portions of the UI to use libhandy widgets.

Reader Mode

Jan-Michael’s reader mode has been available since 3.30, but new to 3.32 are many style improvements and new preferences to choose between dark and light theme, and between sans and serif font, thanks to Adrian (who is, confusingly, not Adrien). The default, sans on light background, still looks the best to me, but if you like serif fonts or dark backgrounds, now you can have them.

JPEG 2000

Wait, JPEG 2000? The obscure image standard not supported by Chrome or Firefox? Why would we add support for this? Simple: websites are using it. A certain piece of popular server-side software is serving JPEG 2000 images in place of normal JPEGs and even in place of PNG images to browsers with Safari-style user agents. (The software in question doesn’t even bother to change the file extensions. We’ve found far too many images in the wild ending in .png that are actually JPEG 2000.) Since this software is used on a fairly large number of websites, and our user agent is too fragile to change, we decided to support JPEG 2000 in order to make these websites work properly. So Carlos has implemented JPEG 2000 support, using the OpenJPEG library.

This isn’t a happy event for the web, because WebKit is only as secure as its least-secure dependency, and adding new obscure image formats is not a step in the right direction. But in this case,  it is necessary.

Mouse Gestures

Experimental mouse gesture support is now available, thanks to Jan-Michael, if you’re willing to use the command line to enable it:

$ gsettings set org.gnome.Epiphany.web:/org/gnome/epiphany/web/ enable-mouse-gestures true

With this, I find myself closing tabs by dragging the mouse down and then to the right. Down and back up will reload the tab. Straight to the left is Back, straight to the right is Forward. Straight down will open a new tab. I had originally hoped to use the right mouse button for this, as in Opera, but turns out there is a difference in context menu behavior: whereas Windows apps normally pop up the context menu on button release, GTK apps open the menu on button press. That means the context menu would appear at the start of every mouse gesture. And that is certainly no good, so we’ve opted to use the middle mouse button instead. We aren’t sure whether this is a good state of things, and need your feedback to decide where to go with this feature.

Improved Fullscreen Mode

A cool side benefit of using libdazzle is that the header bar is now available in fullscreen mode by pressing the mouse towards the top of the screen. There’s even a nice animation to show the header bar sliding up to the top of the screen, so you know it’s there (animation disabled for fullscreen video).

The New Tab Button

Some users were disconcerted that the new tab button would jump from the end of the tab bar (when multiple tabs are open) back up to the end of the header bar (when there is only one tab open). Now this button will remain in one place: the header bar. Since it will no longer appear in the tab bar, Jan-Michael has moved it back to the start of the header bar, where it was from 3.12 through 3.22, rather than the end. This is mostly arbitrary, but makes for a somewhat more balanced layout.

The history of the new tab button is rather fun: when the new tab button was first added in 3.8, it was added at the end of the header bar, but moved to the start in 3.12 to be more consistent with gedit, then moved back to the end in 3.24 to reduce the distance it would need to move to reach the tab bar. So we’ve come full circle here, twice. Only time will tell if this nomadic button will finally be able to stay put.

New Icon

Yes, most GNOME applications have a new icon in 3.32, so Epiphany is not special here. But I just can’t resist the urge to show it off. Thanks, Jakub!

And More…

It’s impossible to mention all the improvements in 3.32 in a single blog post, but I want to squeeze a few more in.

Alexander (Exalm) landed several improvements to Epiphany’s theme, especially the incognito mode theme, which needed work to look good with the new Adwaita in 3.32.

Jan-Michael added an animation for completed downloads, so we don’t need to annoyingly pop open the download popover anymore to let you know that your download has completed.

Carlos Garcia added support for automation mode. This means Epiphany can now be used for running automated tests with WebDriver (e.g. with Selenium). Using the new automation mode, I’ve upstreamed support for running tests with Epiphany to the Web Platform Tests (WPT) project, the test suite used by web engine developers to test standards conformance.

Carlos also reworked the implementation of script dialogs so that they are now modal only to their associated web view, not modal to the entire application. This means you can just close the browser tab if a particular website is abusing script dialogs in a problematic way, e.g. by continuously opening new dialogs.

Patrick has improved the directory layout Epiphany uses to store data on disk to avoid storing non-configuration data under ~/.config, and reworked the internals of the password manager to mitigate Spectre-related concerns. He also implemented Happy Eyeballs support in GLib, so Epiphany will now fall back to an IPv4 connection if IPv6 is available but broken.

Now Contains 100% Less Punctuation!

Did you notice any + signs missing in this blog? Following GTK+’s rename to GTK, WebKitGTK+ has been renamed to WebKitGTK. You’re welcome.

Whither Pop!_OS?

Extra Credit

Although Epiphany 3.32 has been the work of many developers, as you’ve seen, I want to give special credit Epiphany’s newest maintainer, Jan-Michael. He has closed a considerable number of bugs, landed too many improvements to mention here, and has been a tremendous help. Thank you!

Now, onward to 3.34!

by Michael Catanzaro at March 27, 2019 12:41 PM



March 19, 2019

Epiphany Technology Preview Upgrade Requires Manual Intervention

by Michael Catanzaro

Jan-Michael has recently changed Epiphany Technology Preview to use a separate app ID. Instead of org.gnome.Epiphany, it will now be org.gnome.Epiphany.Devel, to avoid clashing with your system version of Epiphany. You can now have separate desktop icons for both system Epiphany and Epiphany Technology Preview at the same time.

Because flatpak doesn’t provide any way to rename an app ID, this means it’s the end of the road for previous installations of Epiphany Technology Preview. Manual intervention is required to upgrade. Fortunately, this is a one-time hurdle, and it is not hard:

$ flatpak uninstall org.gnome.Epiphany

Uninstall the old Epiphany…

$ flatpak install gnome-apps-nightly org.gnome.Epiphany.Devel org.gnome.Epiphany.Devel.Debug

…install the new one, assuming that your remote is named gnome-apps-nightly (the name used locally may differ), and that you also want to install debuginfo to make it possible to debug it…

$ mv ~/.var/app/org.gnome.Epiphany ~/.var/app/org.gnome.Epiphany.Devel

…and move your personal data from the old app to the new one.

Then don’t forget to make it your default web browser under System Settings -> Details -> Default Applications. Thanks for testing Epiphany Technology Preview!

by Michael Catanzaro at March 19, 2019 06:39 PM



March 13, 2019

WebKitGTK 2.24.0 released!

by The WebKitGTK Project

This is the first stable release in the 2.24 series.

Highlights of the WebKitGTK 2.24.0 release

  • Added support for content filtering.
  • Variation fonts support.
  • Fully emoji rendering support.
  • Added navigation and pinch zoom gestures for touchpads.
  • Support for JPEG2000 images.
  • Script dialogs are now modal to the current web view only.
  • New API to convert URI to format for display.

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

Thanks to all the contributors who made possible this release.

March 13, 2019 12:00 AM



March 06, 2019

WebKitGTK 2.23.92 released!

by The WebKitGTK Project

This is a development release leading toward 2.24 series.

What’s new in the WebKitGTK 2.23.92 release?

  • Fix constructors returning a GObject in JSC GLib API.
  • Do not scan NPAPI plugins when plugins are disabled in settings.
  • Add WebKitUserContentFilterStore to the API docs.
  • Fix several crashes and rendering issues.
  • Translation updates: Polish.

Thanks to all the contributors who made possible this release.

March 06, 2019 12:00 AM



March 01, 2019

WebKitGTK 2.22.7 released!

by The WebKitGTK Project

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

What’s new in the WebKitGTK 2.22.7 release?

  • Fix rendering of glyphs in Hebrew (and possibly other languages) when Unicode NFC normalization is used.
  • Fix several crashes and race conditions.

Thanks to all the contributors who made possible this release.

March 01, 2019 12:00 AM



February 20, 2019

WebKitGTK 2.23.91 released!

by The WebKitGTK Project

This is a development release leading toward 2.24 series.

What’s new in the WebKitGTK 2.23.91 release?

  • Add new API to handle user content filters.
  • Fix a UI process crash while filling selection data during drag and drop.
  • Fix deadlock on Linux/x64 between SamplingProfiler and VMTraps.
  • Fix several crashes and rendering issues.
  • Translation updates: Italian.

Thanks to all the contributors who made possible this release.

February 20, 2019 12:00 AM



February 14, 2019

WebKitGTK 2.23.90 released!

by The WebKitGTK Project

This is a development release leading toward 2.24 series.

What’s new in the WebKitGTK 2.23.90 release?

  • Add a new setting to disable JavaScript elments from documents during parsing.
  • Add new API to expose JavaScriptCore options.
  • Add support for JPEG2000 images.
  • Add support for back/forward touchpad gesture.
  • Add support for pinch zoom on touchpad.
  • Use a scrolled window in alert dialogs to handle long contents.
  • Sleep disabler now inhibits idle when a “System” sleep disabler is requested.
  • Remove experimental sandboxing support, it’s not yet ready for stable release.
  • Fix a web process deadlock when starting the remote inspector.
  • Fix a crash when browsing inspector:// URI without port set.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

February 14, 2019 12:00 AM



February 11, 2019

Review of Igalia’s Multimedia Activities (2018/H2)

by Víctor Jáquez

This is the first semiyearly report about Igalia’s activities around multimedia, covering the second half of 2018.

Great length of this report was exposed in Phil’s talk surveying mutimedia development in WebKitGTK and WPE:

WebKit Media Source Extensions (MSE)

MSE is a specification that allows JS to generate media streams for playback for Web browsers that support HTML 5 video and audio.

Last semester we upstreamed the support to WebM format in WebKitGTK with the related patches in GStreamer, particularly in qtdemux, matroskademux elements.

WebKit Encrypted Media Extensions (EME)

EME is a specification for enabling playback of encrypted content in Web bowsers that support HTML 5 video.

In a downstream project for WPE WebKit we managed to have almost full test coverage in the YoutubeTV 2018 test suite.

We merged our contributions in upstream, WebKit and GStreamer, most of what is legal to publish, for example, making demuxers aware of encrypted content and make them to send protection events with the initialization data and the encrypted caps, in order to select later the decryption key.

We started to coordinate the upstreaming process of a new implementation of CDM (Content Decryption Module) abstraction and there will be even changes in that abstraction.

Lighting talk about EME implementation in WPE/WebKitGTK in GStreamer Conference 2018.

WebKit WebRTC

WebRTC consists of several interrelated APIs and real time protocols to enable Web applications and sites to captures audio, or A/V streams, and exchange them between browsers without requiring an intermediary.

We added GStreamer interfaces to LibWebRTC, to use it for the network part, while using GStreamer for the media capture and processing. All that was upstreamed in 2018 H2.

Thibault described thoroughly the tasks done for this achievement.

Talk about WebRTC implementation in WPE/WebKitGTK in WebEngines hackfest 2018.

Servo/media

Servo is a browser engine written in Rust designed for high parallelization and high GPU usage.

We added basic support for <video> and <audio> media elements in Servo. Later on, we added the GstreamerGL bindings for Rust in gstreamer-rs to render GL textures from the GStreamer pipeline in Servo.

Lighting talk in the GStreamer Conference 2018.

GstWPE

Taking an idea from the GStreamer Conference, we developed a GStreamer source element that wraps WPE. With this source element, it is possible to blend a web page and video in a single video stream; that is, the output of a Web browser (to say, a rendered web page) is used as a video source of a GStreamer pipeline: GstWPE. The element is already merged in the gst-plugins-bad repository.

Talk about GstWPE in FOSDEM 2019

Demo #1

Demo #2

GStreamer VA-API and gst-MSDK

At last, but not the least, we continued helping with the maintenance of GStreamer-VAAPI and gst-msdk, with code reviewing and on-going migration of the internal library to GObject.

Other activities

The second half of 2018 was also intense in terms of conferences and hackfest for the team:


Thanks to bear with us along all this blog post and to keeping under your radar our work.

by vjaquez at February 11, 2019 12:52 PM



February 09, 2019

WebKitGTK+ 2.22.6 released!

by The WebKitGTK Project

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

What’s new in the WebKitGTK+ 2.22.6 release?

  • Make kinetic scrolling slow down smoothly when reaching the ends of pages, instead of abruptly, to better match the GTK+ behaviour.
  • Fix Web inspector magnifier under Wayland.
  • Fix garbled rendering of some websites (e.g. YouTube) while scrolling under X11.
  • Fix several crashes, race conditions, and rendering issues.

Thanks to all the contributors who made possible this release.

February 09, 2019 12:00 AM



February 08, 2019

WebKitGTK+ and WPE WebKit Security Advisory WSA-2019-0001

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK+ and WPE WebKit.

  • CVE-2019-6212
    • Versions affected: WebKitGTK+ before 2.22.6 and WPE WebKit before 2.22.4.
    • Credit to an anonymous researcher.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-6215
    • Versions affected: WebKitGTK+ before 2.22.6 and WPE WebKit before 2.22.4.
    • Credit to Lokihardt of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A type confusion issue was addressed with improved memory handling.
  • CVE-2019-6216
    • Versions affected: WebKitGTK+ before 2.22.5 and WPE WebKit before 2.22.3.
    • Credit to Fluoroacetate working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-6217
    • Versions affected: WebKitGTK+ before 2.22.5 and WPE WebKit before 2.22.3.
    • Credit to Fluoroacetate working with Trend Micro’s Zero Day Initiative, Proteas, Shrek_wzw, and Zhuo Liang of Qihoo 360 Nirvan Team.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-6226
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Apple.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2019-6227
    • Versions affected: WebKitGTK+ before 2.22.5 and WPE WebKit before 2.22.3.
    • Credit to Qixun Zhao of Qihoo 360 Vulcan Team.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2019-6229
    • Versions affected: WebKitGTK+ before 2.22.5 and WPE WebKit before 2.22.3.
    • Credit to Ryan Pickren.
    • Processing maliciously crafted web content may lead to universal cross site scripting. A logic issue was addressed with improved validation.
  • CVE-2019-6233
    • Versions affected: WebKitGTK+ before 2.22.4 and WPE WebKit before 2.22.2.
    • Credit to G. Geshev from MWR Labs working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2019-6234
    • Versions affected: WebKitGTK+ before 2.22.4 and WPE WebKit before 2.22.2.
    • Credit to G. Geshev from MWR Labs working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.

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

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

February 08, 2019 12:00 AM



January 14, 2019

WebKitGTK+ 2.23.3 released!

by The WebKitGTK Project

This is a development release leading toward 2.24 series.

What’s new in the WebKitGTK+ 2.23.3 release?

  • Fix rendering of emoji sequences containing zero width joiner.
  • Fallback to a colored font when rendering emojis.
  • Fix rendering artifacts on Youtube while scrolling under X11.
  • Remove DConf permissions from sandbox.
  • Fix build from release tarball with gtkdoc enabled.
  • Fix several crashes and rendering issues.
  • Translation updates: Swedish

Thanks to all the contributors who made possible this release.

January 14, 2019 12:00 AM



January 08, 2019

Epiphany automation mode

by Carlos García Campos

Last week I finally found some time to add the automation mode to Epiphany, that allows to run automated tests using WebDriver. It’s important to note that the automation mode is not expected to be used by users or applications to control the browser remotely, but only by WebDriver automated tests. For that reason, the automation mode is incompatible with a primary user profile. There are a few other things affected by the auotmation mode:

  • There’s no persistency. A private profile is created in tmp and only ephemeral web contexts are used.
  • URL entry is not editable, since users are not expected to interact with the browser.
  • An info bar is shown to notify the user that the browser is being controlled by automation.
  • The window decoration is orange to make it even clearer that the browser is running in automation mode.

So, how can I write tests to be run in Epiphany? First, you need to install a recently enough selenium. For now, only the python API is supported. Selenium doesn’t have an Epiphany driver, but the WebKitGTK driver can be used with any WebKitGTK+ based browser, by providing the browser information as part of session capabilities.

from selenium import webdriver

options = webdriver.WebKitGTKOptions()
options.binary_location = 'epiphany'
options.add_argument('--automation-mode')
options.set_capability('browserName', 'Epiphany')
options.set_capability('version', '3.31.4')

ephy = webdriver.WebKitGTK(options=options, desired_capabilities={})
ephy.get('http://www.webkitgtk.org')
ephy.quit()

This is a very simple example that just opens Epiphany in automation mode, loads http://www.webkitgtk.org and closes Epiphany. A few comments about the example:

  • Version 3.31.4 will be the first one including the automation mode.
  • The parameter desired_capabilities shouldn’t be needed, but there’s a bug in selenium that has been fixed very recently.
  • WebKitGTKOptions.set_capability was added in selenium 3.14, if you have an older version you can use the following snippet instead
from selenium import webdriver

options = webdriver.WebKitGTKOptions()
options.binary_location = 'epiphany'
options.add_argument('--automation-mode')
capabilities = options.to_capabilities()
capabilities['browserName'] = 'Epiphany'
capabilities['version'] = '3.31.4'

ephy = webdriver.WebKitGTK(desired_capabilities=capabilities)
ephy.get('http://www.webkitgtk.org')
ephy.quit()

To simplify the driver instantation you can create your own Epiphany driver derived from the WebKitGTK one:

from selenium import webdriver

class Epiphany(webdriver.WebKitGTK):
    def __init__(self):
        options = webdriver.WebKitGTKOptions()
        options.binary_location = 'epiphany'
        options.add_argument('--automation-mode')
        options.set_capability('browserName', 'Epiphany')
        options.set_capability('version', '3.31.4')

        webdriver.WebKitGTK.__init__(self, options=options, desired_capabilities={})

ephy = Epiphany()
ephy.get('http://www.webkitgtk.org')
ephy.quit()

The same for selenium < 3.14

from selenium import webdriver

class Epiphany(webdriver.WebKitGTK):
    def __init__(self):
        options = webdriver.WebKitGTKOptions()
        options.binary_location = 'epiphany'
        options.add_argument('--automation-mode')
        capabilities = options.to_capabilities()
        capabilities['browserName'] = 'Epiphany'
        capabilities['version'] = '3.31.4'

        webdriver.WebKitGTK.__init__(self, desired_capabilities=capabilities)

ephy = Epiphany()
ephy.get('http://www.webkitgtk.org')
ephy.quit()

by carlos garcia campos at January 08, 2019 05:22 PM



WebKitGTK+ 2.23.2 released!

by The WebKitGTK Project

This is a development release leading toward 2.24 series.

What’s new in the WebKitGTK+ 2.23.2 release?

  • Fix rendering artifacts in some websites with accelerated compositing enabled.
  • Add initial support for variation fonts.
  • Add new API to convert a URI to a format for display.
  • Make scrollbars follow gtk-primary-button-warps-slider setting.
  • Fix crashes when closing the WebDriver session.
  • Fix the build with OpenGL disabled.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

January 08, 2019 12:00 AM



December 13, 2018

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

by The WebKitGTK Project

Several vulnerabilities were discovered in WebKitGTK+ and WPE WebKit.

  • CVE-2018-4437
    • Versions affected: WebKitGTK+ before 2.22.5 and WPE WebKit before 2.22.3.
    • Credit to HyungSeok Han, DongHyeon Oh, and Sang Kil Cha of KAIST Softsec Lab, Korea.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4438
    • Versions affected: WebKitGTK+ before 2.22.3 and WPE WebKit before 2.22.1.
    • Credit to lokihardt of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A logic issue existed resulting in memory corruption. This was addressed with improved state management.
  • CVE-2018-4441
    • Versions affected: WebKitGTK+ before 2.22.3 and WPE WebKit before 2.22.1.
    • Credit to lokihardt of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2018-4442
    • Versions affected: WebKitGTK+ before 2.22.3 and WPE WebKit before 2.22.1.
    • Credit to lokihardt of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2018-4443
    • Versions affected: WebKitGTK+ before 2.22.3 and WPE WebKit before 2.22.1.
    • Credit to lokihardt of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved memory handling.
  • CVE-2018-4464
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to HyungSeok Han, DongHyeon Oh, and Sang Kil Cha of KAIST Softsec Lab, Korea.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.

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

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

December 13, 2018 12:00 AM



WebKitGTK+ 2.22.5 released!

by The WebKitGTK Project

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

What’s new in the WebKitGTK+ 2.22.5 release?

  • Improved the logic to determine for which architectures to enable the JIT compiler support and USE_SYSTEM_MALLOC at build time.
  • Fix the build with ENABLE_VIDEO=OFF and ENABLE_OPENGL=OFF.
  • Fix several crashes.

Thanks to all the contributors who made possible this release.

December 13, 2018 12:00 AM



December 08, 2018

Web overlay in GStreamer with WPEWebKit

by Philippe Normand

After a year or two of hiatus I attended the GStreamer conference which happened in beautiful Edinburgh. It was great to meet the friends from the community again and learn about what’s going on in the multimedia world. The quality of the talks was great, the videos are published …

by Philippe Normand at December 08, 2018 02:09 PM



November 22, 2018

WebKitGTK+ 2.23.1 released!

by The WebKitGTK Project

This is the first development release leading toward 2.24 series.

What’s new in the WebKitGTK+ 2.23.1 release?

  • Add initial support for subprocess sandboxing in Linux.
  • Add new permission request type for media device information.
  • Make scrollbars follow gtk-primary-button-warps-slider setting.
  • Script dialogs are now modal to the current web view only.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

November 22, 2018 12:00 AM



November 21, 2018

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

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+ and WPE WebKit.

  • CVE-2018-4345
    • Versions affected: WebKitGTK+ before 2.22.3 and WPE WebKit before 2.22.1.
    • Credit to an anonymous researcher.
    • A cross-site scripting issue existed in WebKit. This issue was addressed with improved URL validation.
  • CVE-2018-4372
    • Versions affected: WebKitGTK+ before 2.22.4 and WPE WebKit before 2.22.2.
    • Credit to HyungSeok Han, DongHyeon Oh, and Sang Kil Cha of KAIST Softsec Lab, Korea.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4373
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to ngg, alippai, DirtYiCE, KT of Tresorit working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4375
    • Versions affected: WebKitGTK+ before 2.22.1 and WPE WebKit before 2.22.0.
    • Credit to Yu Haiwan and Wu Hongjun From Nanyang Technological University working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4376
    • Versions affected: WebKitGTK+ before 2.22.1 and WPE WebKit before 2.22.0.
    • Credit to 010 working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4378
    • Versions affected: WebKitGTK+ before 2.22.1 and WPE WebKit before 2.22.0.
    • Credit to an anonymous researcher, zhunki of 360 ESG Codesafe Team.
    • Processing maliciously crafted web content may lead to code execution. A memory corruption issue was addressed with improved validation.
  • CVE-2018-4382
    • Versions affected: WebKitGTK+ before 2.22.1 and WPE WebKit before 2.22.0.
    • Credit to lokihardt of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4386
    • Versions affected: WebKitGTK+ before 2.22.3 and WPE WebKit before 2.22.1.
    • Credit to lokihardt of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4392
    • Versions affected: WebKitGTK+ before 2.22.1 and WPE WebKit before 2.22.0.
    • Credit to zhunki of 360 ESG Codesafe Team.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4416
    • Versions affected: WebKitGTK+ before 2.22.1 and WPE WebKit before 2.22.0.
    • Credit to lokihardt of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.

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

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

November 21, 2018 12:00 AM



WebKitGTK+ 2.22.4 released!

by The WebKitGTK Project

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

What’s new in the WebKitGTK+ 2.22.4 release?

  • Expose ENABLE_MEDIA_SOURCE as a public build option.
  • Fix a crash when using Cairo versions between 1.15 and 1.16.0
  • Fix the build with -DLOG_DISABLED=0.
  • Fix the build with ENABLE_VIDEO=OFF and ENABLE_WEB_AUDIO=OFF.
  • Fix debug builds of JavaScriptCore.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

November 21, 2018 12:00 AM



November 12, 2018

The GNOME (and WebKitGTK+) Networking Stack

by Michael Catanzaro

WebKit currently has four network backends:

  • CoreFoundation (used by macOS and iOS, and thus Safari)
  • CFNet (used by iTunes on Windows… I think only iTunes?)
  • cURL (used by most Windows applications, also PlayStation)
  • libsoup (used by WebKitGTK+ and WPE WebKit)

One guess which of those we’re going to be talking about in this post. Yeah, of course, libsoup! If you’re not familiar with libsoup, it’s the GNOME HTTP library. Why is it called libsoup? Because before it was an HTTP library, it was a SOAP library. And apparently somebody thought that when Mexican people say “soap,” it often sounds like “soup,” and also thought that this was somehow both funny and a good basis for naming a software library. You can’t make this stuff up.

Anyway, libsoup is built on top of GIO’s sockets APIs. Did you know that GIO has Object wrappers for BSD sockets? Well it does. If you fancy lower-level APIs, create a GSocket and have a field day with it. Want something a bit more convenient? Use GSocketClient to create a GSocketConnection connected to a GNetworkAddress. Pretty straightforward. Everything parallels normal BSD sockets, but the API is nice and modern and GObject, and that’s really all there is to know about it. So when you point WebKitGTK+ at an HTTP address, libsoup is using those APIs behind the scenes to handle connection establishment. (We’re glossing over details like “actually implementing HTTP” here. Trust me, libsoup does that too.)

Things get more fun when you want to load an HTTPS address, since we have to add TLS to the picture, and we can’t have TLS code in GIO or GLib due to this little thing called “copyright law.” See, there are basically three major libraries used to implement TLS on Linux, and they all have problems:

  • OpenSSL is by far the most popular, but it’s, hm, shall we say technically non-spectacular. There are forks, but the forks have problems too (ask me about BoringSSL!), so forget about them. The copyright problem here is that the OpenSSL license is incompatible with the GPL. (Boring details: Red Hat waves away this problem by declaring OpenSSL a system library qualifying for the GPL’s system library exception. Debian has declared the opposite, so Red Hat’s choice doesn’t gain you anything if you care about Debian users. The OpenSSL developers are trying to relicense to the Apache license to fix this, but this process is taking forever, and the Apache license is still incompatible with GPLv2, so this would make it impossible to use GPLv2+ software except under the terms of GPLv3+. Yada yada details.) So if you are writing a library that needs to be used by GPL applications, like say GLib or libsoup or WebKit, then it would behoove you to not use OpenSSL.
  • GnuTLS is my favorite from a technical standpoint. Its license is LGPLv2+, which is unproblematic everywhere, but some of its dependencies are licensed LGPLv3+, and that’s uncomfortable for many embedded systems vendors, since LGPLv3+ contains some provisions that make it difficult to deny you your freedom to modify the LGPLv3+ software. So if you rely on embedded systems vendors to fund the development of your library, like say libsoup or WebKit, then you’re really going to want to avoid GnuTLS.
  • NSS is used by Firefox. I don’t know as much about it, because it’s not as popular. I get the impression that it’s more designed for the needs of Firefox than as a Linux system library, but it’s available, and it works, and it has no license problems.

So naturally GLib uses NSS to avoid the license issues of OpenSSL and GnuTLS, right?

Haha no, it uses a dynamically-loadable extension point system to allow you to pick your choice of OpenSSL or GnuTLS! (Support for NSS was started but never finished.) This is OK because embedded systems vendors don’t use GPL applications and have no problems with OpenSSL, while desktop Linux users don’t produce tivoized embedded systems and have no problems with LGPLv3. So if you’re using desktop Linux and point WebKitGTK+ at an HTTPS address, then GLib is going to load a GIO extension point called glib-networking, which implements all of GIO’s TLS APIs — notably GTlsConnection and GTlsCertificate — using GnuTLS. But if you’re building an embedded system, you simply don’t build or install glib-networking, and instead build a different GIO extension point called glib-openssl, and libsoup will create GTlsConnection and GTlsCertificate objects based on OpenSSL instead. Nice! And if you’re Centricular and you’re building GStreamer for Windows, you can use yet another GIO extension point, glib-schannel, for your native Windows TLS goodness, all hidden behind GTlsConnection so that GStreamer (or whatever application you’re writing) doesn’t have to know about SChannel or OpenSSL or GnuTLS or any of that sad complexity.

Now you know why the TLS extension point system exists in GIO. Software licenses! And you should not be surprised to learn that direct use of any of these crypto libraries is banned in libsoup and WebKit: we have to cater to both embedded system developers and to GPL-licensed applications. All TLS library use is hidden behind the GTlsConnection API, which is really quite nice to use because it inherits from GIOStream. You ask for a TLS connection, have it handed to you, and then read and write to it without having to deal with any of the crypto details.

As a recap, the layering here is: WebKit -> libsoup -> GIO (GLib) -> glib-networking (or glib-openssl or glib-schannel).

So when Epiphany fails to load a webpage, and you’re looking at a TLS-related error, glib-networking is probably to blame. If it’s an HTTP-related error, the fault most likely lies in libsoup. Same for any other GNOME applications that are having connectivity troubles: they all use the same network stack. And there you have it!

P.S. The glib-openssl maintainers are helping merge glib-openssl into glib-networking, such that glib-networking will offer a choice of GnuTLS or OpenSSL and obsoleting glib-openssl. This is still a work in progress. glib-schannel will be next!

P.S.S. libcurl also gives you multiple choices of TLS backend, but makes you choose which at build time, whereas with GIO extension points it’s actually possible to choose at runtime from the selection of installed extension points. The libcurl approach is fine in theory, but creates some weird problems, e.g. different backends with different bugs are used on different distributions. On Fedora, it used to use NSS, but now uses OpenSSL, which is fine for Fedora, but would be a license problem elsewhere. Debian actually builds several different backends and gives you a choice, unlike everywhere else. I digress.

by Michael Catanzaro at November 12, 2018 04:51 AM



November 07, 2018

Mesa Update Breaks WebKitGTK+ in Fedora 29

by Michael Catanzaro

If you’re using Fedora and discovered that WebKitGTK+ is displaying blank pages, the cause is a bad mesa update, mesa-18.2.3-1.fc29. This in turn was caused by a GCC bug that resulted in miscompilation of mesa.

To avoid this bug, downgrade to mesa-18.2.2-1.fc29:

$ sudo dnf downgrade mesa*

You can also update to mesa-18.2.4-2.fc29, but this build has not yet reached updates-testing, let alone stable, so downgrading is easier for now. Another workaround is to run your application with accelerated compositing mode disabled, to avoid OpenGL usage:

$ WEBKIT_DISABLE_COMPOSITING_MODE=1 epiphany

On the bright side of things, from all the bug reports I’ve received over the past two days I’ve discovered that lots of people use Epiphany and notice when it’s broken. That’s nice!

Huge thanks to Dave Airlie for quickly preparing the fixed mesa update, and to Jakub Jelenik for handling the same for GCC.

by Michael Catanzaro at November 07, 2018 02:28 AM



November 03, 2018

WebKitGTK+ 2.22.2 and 2.22.3, Media Source Extensions, and YouTube

by Michael Catanzaro

Last month, I attended the Web Engines Hackfest (hosted by Igalia in A Coruña, Spain) and also the WebKit Contributors Meeting (hosted by Apple in San Jose, California). These are easily the two biggest WebKit development events of the year, and it’s always amazing to meet everyone in person yet again. A Coruña is an amazing city, and every browser developer ought to visit at least once. And the Contributors Meeting is a no-brainer event for WebKit developers.

One of the main discussion points this year was Media Source Extensions (MSE). MSE is basically a way for browsers to control how videos are downloaded. Until recently, if you were to play a YouTube video in Epiphany, you’d notice that the video loads way faster than it does in other browsers. This is because WebKitGTK+ — until recently — had no support for MSE. In other browsers, YouTube uses MSE to limit the speed at which video is downloaded, in order to reduce wasted bandwidth in case you stop watching the video before it ends. But with WebKitGTK+, MSE was not available, so videos would load as quickly as possible. MSE also makes it harder for browsers to offer the ability to download the videos; you’ll notice that neither Firefox nor Chrome offer to download the videos in their context menus, a feature that’s been available in Epiphany for as long as I remember.

So that sounds like it’s good to not have MSE. Well, the downside is that YouTube requires it in order to receive HD videos, to avoid that wasted bandwidth and to make it harder for users to download HD videos. And so WebKitGTK+ users have been limited to 720p video with H.264 and 480p video with WebM, where other browsers had access to 1080p and 1440p video. I’d been stuck with 480p video on Fedora for so long, I’d forgotten that internet video could look good.

Unfortunately, WebKitGTK+ was quite late to implement MSE. All other major browsers turned it on several years ago, but WebKitGTK+ dawdled. There was some code to support MSE, but it didn’t really work, and was disabled. And so it came to pass that, in September of this year, YouTube began to require MSE to access any WebM video, and we had a crisis. We don’t normally enable major new features in stable releases, but this was an exceptional situation and users would not be well-served by delaying until the next release cycle. So within a couple weeks, we were able to release WebKitGTK+ 2.22.2 and Epiphany 3.30.1 (both on September 21), and GStreamer 1.14.4 (on October 2, thanks to Tim-Philipp Müller for expediting that release). Collectively, these releases enabled basic video playback with MSE for users of GNOME 3.30. And if you still use of GNOME 3.28, worry not: you are still supported and can get MSE if you update to Epiphany 3.28.5 and also have the aforementioned versions of WebKitGTK+ and GStreamer.

MSE in WebKitGTK+ 2.22.2 had many rough edges because it was a mad rush to get the feature into a minimally-viable state, but those issues have been polished off in 2.22.3, which we released earlier this week on October 29. Be sure you have WebKitGTK+ 2.22.3, plus GStreamer 1.14.4, for a good experience on YouTube. Unfortunately we can’t provide support for older software versions anymore: if you don’t have GStreamer 1.14.4, then you’ll need to configure WebKitGTK+ with -DENABLE_MEDIA_SOURCE=OFF at build time and suffer from lack of MSE.

Epiphany 3.28.1 uses WebKitSettings to turn on the “enable-mediasource” setting. Turn that on if your application wants MSE now (if it’s a web browser, it certainly does). This setting will be enabled by default in WebKitGTK+ 2.24. Huge thanks to the talented developers who made this feature possible! Enjoy your 1080p and 1440p video.

by Michael Catanzaro at November 03, 2018 04:19 AM



On WebKit Build Options (Also: How to Accidentally Disable Important Security Features!)

by Michael Catanzaro

When building WebKitGTK+, it’s a good idea to stick to the default values for the build options. If you’re building some sort of embedded system and really know what you’re doing, then OK, it might make sense to change some settings and disable some stuff. But Linux distros are generally well-advised to stick to the defaults to avoid creating problems for users.

One exception is if you need to disable certain features to avoid newer dependencies when building WebKit for older systems. For example, Ubuntu 18.04 disables web fonts (ENABLE_WOFF2=OFF) because it doesn’t have the libbrotli and libwoff2 dependencies that are required for that feature to work, hence some webpages will display using subpar fonts. And distributions shipping older versions of GStreamer will need to disable the ENABLE_MEDIA_SOURCE option (which is missing from the below feature list by mistake), since that requires the very latest GStreamer to work.

Other exceptions are the ENABLE_GTKDOC and ENABLE_MINIBROWSER settings, which distros do want. ENABLE_GTKDOC is disabled by default because it’s slow to build, and ENABLE_MINIBROWSER because, well, actually I don’t know why, you always want that one and it’s just annoying to find it’s not built.

OK, but really now, other than those exceptions, you should probably leave the defaults alone.

The feature list that prints when building WebKitGTK+ looks like this:

--  ENABLE_ACCELERATED_2D_CANVAS .......... OFF
--  ENABLE_DRAG_SUPPORT                     ON
--  ENABLE_GEOLOCATION .................... ON
--  ENABLE_GLES2                            OFF
--  ENABLE_GTKDOC ......................... OFF
--  ENABLE_ICONDATABASE                     ON
--  ENABLE_INTROSPECTION .................. ON
--  ENABLE_JIT                              ON
--  ENABLE_MINIBROWSER .................... OFF
--  ENABLE_OPENGL                           ON
--  ENABLE_PLUGIN_PROCESS_GTK2 ............ ON
--  ENABLE_QUARTZ_TARGET                    OFF
--  ENABLE_SAMPLING_PROFILER .............. ON
--  ENABLE_SPELLCHECK                       ON
--  ENABLE_TOUCH_EVENTS ................... ON
--  ENABLE_VIDEO                            ON
--  ENABLE_WAYLAND_TARGET ................. ON
--  ENABLE_WEBDRIVER                        ON
--  ENABLE_WEB_AUDIO ...................... ON
--  ENABLE_WEB_CRYPTO                       ON
--  ENABLE_X11_TARGET ..................... ON
--  USE_LIBHYPHEN                           ON
--  USE_LIBNOTIFY ......................... ON
--  USE_LIBSECRET                           ON
--  USE_SYSTEM_MALLOC ..................... OFF
--  USE_WOFF2                               ON

And, asides from the exceptions noted above, those are probably the options you want to ship with.

Why are some things disabled by default? ENABLE_ACCELERATED_2D_CANVAS is OFF by default because it is experimental (i.e. not great :) and requires CairoGL, which has been available in most distributions for about half a decade now, but still hasn’t reached Debian yet, because the Debian developers know that the Cairo developers consider CarioGL experimental (i.e. not great!). Many of our developers use Debian, and we’re not keen on having two separate sets of canvas bugs depending on whether you’re using Debian or not, so best keep this off for now. ENABLE_GLES2 switches you from desktop GL to GLES, which is maybe needed for embedded systems with crap proprietary graphics drivers, but certainly not what you want when building for a general-purpose distribution with mesa. Then ENABLE_QUARTZ_TARGET is for building on macOS, not for Linux. And then we come to USE_SYSTEM_MALLOC.

USE_SYSTEM_MALLOC disables WebKit’s bmalloc memory allocator (“fast malloc”) in favor of glibc malloc. bmalloc is performance-optimized for macOS, and I’m uncertain how its performance compares to glibc malloc on Linux. Doesn’t matter really, because bmalloc contains important heap security features that will be disabled if you switch to glibc malloc, and that’s all you need to know to decide which one to use. If you disable bmalloc, you lose the Gigacage, isolated heaps, heap subspaces, etc. I don’t pretend to understand how any of those things work, so I’ll just refer you to this explanation by Sam Brown, who sounds like he knows what he’s talking about. The point is that, if an attacker has found a memory vulnerability in WebKit, these heap security features make it much harder to exploit and take control of users’ computers, and you don’t want them turned off.

USE_SYSTEM_MALLOC is currently enabled (bad!) in openSUSE and SUSE Linux Enterprise 15, presumably because when the Gigacage was originally introduced, it crashed immediately for users who set address space (virtual memory allocation) limits. Gigacage works by allocating a huge address space to reduce the chances that an attacker can find pointers within that space, similar to ASLR, so limiting the size of the address space prevents Gigacage from working. At first we thought it made more sense to crash than to allow a security feature to silently fail, but we got a bunch of complaints from users who use ulimit to limit the address space used by processes, and also from users who disable overcommit (which is required for Gigacage to allocate ludicrous amounts of address space), and so nowadays we just silently disable Gigacage instead if enough address space for it cannot be allocated. So hopefully there’s no longer any reason to disable this important security feature at build time! Distributions should be building with the default USE_SYSTEM_MALLOC=OFF.

The openSUSE CMake line currently looks like this:

%cmake \
  -DCMAKE_BUILD_TYPE=Release \
  -DLIBEXEC_INSTALL_DIR=%{_libexecdir}/libwebkit2gtk%{_wk2sover} \
  -DPORT=GTK \
%if 0%{?suse_version} == 1315
  -DCMAKE_C_COMPILER=gcc-7 \
  -DCMAKE_CXX_COMPILER=g++-7 \
  -DENABLE_WEB_CRYPTO=OFF \
  -DUSE_GSTREAMER_GL=false \
%endif
%if 0%{?suse_version} <= 1500
  -DUSE_WOFF2=false \
%endif
  -DENABLE_MINIBROWSER=ON \
%if %{with python3}
  -DPYTHON_EXECUTABLE=%{_bindir}/python3 \
%endif
%if !0%{?is_opensuse}
  -DENABLE_PLUGIN_PROCESS_GTK2=OFF \
%endif
%ifarch armv6hl ppc ppc64 ppc64le riscv64 s390 s390x
  -DENABLE_JIT=OFF \
%endif
  -DUSE_SYSTEM_MALLOC=ON \
  -DCMAKE_EXE_LINKER_FLAGS="-Wl,--as-needed -Wl,-z,now -pthread" \
  -DCMAKE_MODULE_LINKER_FLAGS="-Wl,--as-needed -Wl,-z,now -pthread" \
  -DCMAKE_SHARED_LINKER_FLAGS="-Wl,--as-needed -Wl,-z,now -pthread"

which all looks pretty reasonable to me: certain features that require “newer” dependencies are disabled on the old distros, and NPAPI plugins are not supported in the enterprise distro, and JIT doesn’t work on odd architectures. I would remove the ENABLE_JIT=OFF lines only because WebKit’s build system should be smart enough nowadays to disable it automatically to save you the trouble of thinking about which architectures the JIT works on. And I would also remove the -DUSE_SYSTEM_MALLOC=ON line to ensure users are properly protected.

by Michael Catanzaro at November 03, 2018 03:29 AM



October 29, 2018

WebKitGTK+ 2.22.3 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.22.3 release?

  • Many improvements and fixes for video playback with media source extensions (MSE), which improve the user experience across the board, and in particular for playback of WebM videos.
  • Fix a memory leak during media playback when using playbin3.
  • Fix portions of Web views not being rendered after resizing.
  • Fix Resource Timing reporting for <iframe> elements.
  • Fix the build with the remote Web Inspector disabled.
  • Fix the build on ARMv7 with NEON extensions.
  • Fix several crashes and rendering issues.

Thanks to all the contributors who made possible this release.

October 29, 2018 12:00 AM



September 26, 2018

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

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+ and WPE WebKit.

  • CVE-2018-4207
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to Google OSS-Fuzz.
    • Unexpected interaction causes an ASSERT failure. This issue was addressed with improved checks.
  • CVE-2018-4208
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to Google OSS-Fuzz.
    • Unexpected interaction causes an ASSERT failure. This issue was addressed with improved checks.
  • CVE-2018-4209
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to Google OSS-Fuzz.
    • Unexpected interaction causes an ASSERT failure. This issue was addressed with improved checks.
  • CVE-2018-4210
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to Google OSS-Fuzz.
    • Unexpected interaction with indexing types caused a failure. An array indexing issue existed in the handling of a function in JavaScriptCore. This issue was addressed with improved checks.
  • CVE-2018-4212
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to Google OSS-Fuzz.
    • Unexpected interaction causes an ASSERT failure. This issue was addressed with improved checks.
  • CVE-2018-4213
    • Versions affected: WebKitGTK+ before 2.20.0.
    • Credit to Google OSS-Fuzz.
    • Unexpected interaction causes an ASSERT failure. This issue was addressed with improved checks.
  • CVE-2018-4191
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Google OSS-Fuzz.
    • Unexpected interaction causes an ASSERT failure. A memory corruption issue was addressed with improved validation.
  • CVE-2018-4197
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Ivan Fratric of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A use after free issue was addressed with improved memory management.
  • CVE-2018-4299
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Samuel Groβ (saelo) working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4306
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Ivan Fratric of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A use after free issue was addressed with improved memory management.
  • CVE-2018-4309
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to an anonymous researcher working with Trend Micro’s Zero Day Initiative.
    • A malicious website may be able to execute scripts in the context of another website. A cross-site scripting issue existed in WebKit. This issue was addressed with improved URL validation.
  • CVE-2018-4311
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Erling Alf Ellingsen (@steike).
    • Cross-origin SecurityErrors includes the accessed frame’s origin. The issue was addressed by removing origin information.
  • CVE-2018-4312
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Ivan Fratric of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A use after free issue was addressed with improved memory management.
  • CVE-2018-4314
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Ivan Fratric of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A use after free issue was addressed with improved memory management.
  • CVE-2018-4315
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Ivan Fratric of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A use after free issue was addressed with improved memory management.
  • CVE-2018-4316
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to crixer, Hanming Zhang (@4shitak4) of Qihoo 360 Vulcan Team.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A memory corruption issue was addressed with improved state management.
  • CVE-2018-4317
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Ivan Fratric of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A use after free issue was addressed with improved memory management.
  • CVE-2018-4318
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Ivan Fratric of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. A use after free issue was addressed with improved memory management.
  • CVE-2018-4319
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to John Pettitt of Google.
    • A malicious website may cause unexepected cross-origin behavior. A cross-origin issue existed with iframe elements. This was addressed with improved tracking of security origins.
  • CVE-2018-4323
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Ivan Fratric of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4328
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Ivan Fratric of Google Project Zero.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4358
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to @phoenhex team (@bkth_ @5aelo @_niklasb) working with Trend Micro’s Zero Day Initiative.
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4359
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Samuel Groß (@5aelo).
    • Processing maliciously crafted web content may lead to arbitrary code execution. Multiple memory corruption issues were addressed with improved memory handling.
  • CVE-2018-4361
    • Versions affected: WebKitGTK+ and WPE WebKit before 2.22.0.
    • Credit to Google OSS-Fuzz.
    • Unexpected interaction causes an ASSERT failure. A memory corruption issue was addressed with improved memory handling.

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

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

September 26, 2018 12:00 AM



September 21, 2018

WebKitGTK+ 2.22.2 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.22.2 release?

  • Several fixes for video playback with media source extensions (MSE). This allows using WebM support for YouTube, which no longer works through regular video source. Note that MSE is still disabled by default and webkit_settings_set_enable_mediasource() has to be used to enable the feature.
  • Fix the build when only Wayland support is enabled and X11 headers are not available.

Thanks to all the contributors who made possible this release.

September 21, 2018 12:00 AM



September 20, 2018

WebKitGTK+ 2.22.1 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.22.1 release?

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

Thanks to all the contributors who made possible this release.

September 20, 2018 12:00 AM



September 03, 2018

WebKitGTK+ 2.22.0 released!

by The WebKitGTK+ Project

This is the first stable release in the 2.22 series.

Highlights of the WebKitGTK+ 2.22.0 release

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

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

Thanks to all the contributors who made possible this release.

September 03, 2018 12:00 AM



August 24, 2018

WebKitGTK+ 2.21.92 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.22 series.

What’s new in the WebKitGTK+ 2.21.92 release?

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

Thanks to all the contributors who made possible this release.

August 24, 2018 12:00 AM



August 16, 2018

WebKitGTK+ 2.21.91 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.22 series.

What’s new in the WebKitGTK+ 2.21.91 release?

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

Thanks to all the contributors who made possible this release.

August 16, 2018 12:00 AM



August 13, 2018

WebKitGTK+ 2.20.5 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.20.5 release?

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

Thanks to all the contributors who made possible this release.

August 13, 2018 12:00 AM



August 07, 2018

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

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+ and WPE WebKit.

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

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

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

August 07, 2018 12:00 AM



August 06, 2018

WebKitGTK+ 2.20.4 released!

by The WebKitGTK+ Project

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

What’s new in the WebKitGTK+ 2.20.4 release?

Thanks to all the contributors who made possible this release.

August 06, 2018 12:00 AM



July 21, 2018

On Flatpak Nightlies

by Michael Catanzaro

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

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

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

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

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

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

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



July 20, 2018

WebKitGTK+ 2.21.5 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.22 series.

What’s new in the WebKitGTK+ 2.21.5 release?

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

Thanks to all the contributors who made possible this release.

July 20, 2018 12:00 AM



June 13, 2018

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

by The WebKitGTK+ Project

Several vulnerabilities were discovered in WebKitGTK+ and WPE WebKit.

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

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

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

June 13, 2018 12:00 AM



June 12, 2018

WebKitGTK+ 2.21.4 released!

by The WebKitGTK+ Project

This is a development release leading toward 2.22 series.

What’s new in the WebKitGTK+ 2.21.4 release?

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

Thanks to all the contributors who made possible this release.

June 12, 2018 12:00 AM