Re: [webkit-gtk] [Q] How to intercept file requests?

[Michael Catanzaro]

On Fri, Feb 23 2024 at 07:57:54 AM +08:00:00, yfwz...@hotmail.com wrote:

Can I use web process extention to implement this?


You can use a web process extension to inject JavaScript that runs when 
the page loads and try to accomplish what you want that way. In 
Epiphany, look at ephy_web_process_extension_initialize() and 
window_object_cleared_cb() for examples. Some other signals you might 
need, depending on what exactly you're trying to do: 
WebKitWebProcessExtension::page-created (this corresponds to a 
WebKitWebPage object, not the particular web page that you're loading) 
and WebKitWebProcessExtension::document-loaded



___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] [Q] How to intercept file requests?

[Michael Catanzaro]

Hi, there's no way to do this. If you control the web content yourself, 
you could define your own URI scheme. Otherwise, you can probably find 
a way to do whatever it is you want to do by injecting JavaScript. Good 
luck,


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] webview in GTK4 apps?

[Michael Catanzaro]

WebKitGTK works fine with GTK 4. You have three API versions to choose 
from:


* webkit2gtk-4.0: GTK 3, libsoup 2
* webkit2gtk-4.1: GTK 3, libsoup 3
* webkitgtk-6.0: GTK4, libsoup 3

I've never heard of the webview project before, but from a quick look 
it is using webkit2gtk-4.0 unfortunately.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Displaying very long HTML documents (books), etc.

[Michael Catanzaro]

On Wed, Feb 7 2024 at 03:54:40 PM +02:00:00, Sim Tov  
wrote:
1. What is the maximal HTML document size that still can be displayed 
smoothly?

2. Is there a hard limit enforced by WebkitGT


There is no max size. Loading performance will get worse as the max 
document size increases. My suggestion is to just try it and see if 
it's a problem in practice or not. My suspicion is that it will be able 
to handle even extremely long books adequately, but I don't know for 
sure.


3. Are you aware of any apps implementing the two features mentioned 
in the previous email (so I can look for examples/ideas there)?


No, sorry.

Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Displaying very long HTML documents (books), etc.

[Michael Catanzaro]

On Wed, Feb 7 2024 at 03:31:29 PM +02:00:00, Sim Tov  
wrote:
1. The target documents might be very long - books. Does WebkitGTK 
know how to deal with this? Can it load/unload dynamically certain 
portions of the HTML document in order to hold in memory only what's 
visible (in order not to collapse/stay responsive)? Probably a 
similar mechanism is used when dealing with webpages with "infinite" 
scrolling...


Nope. You'll have to handle that yourself.

2. The source file will be displayed in GtkSourceView. Is there a way 
to implement synchronized scrolling, i.e. when the user scrolls the 
source in GtkSourceView the rendered document will scroll accordingly 
inside WebkitGTK (and vise versa)? It's probably also important to 
implement bookmarks, i.e. save the place where the reader left 
reading and closed the app, so it can be focused on that same spot on 
the next app launch.


I'm sure it's all possible, but it will have to be done manually. Good 
luck. :)


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] webkit-gtk for Windows

[Michael Catanzaro]

Hi,

The answer is no.

You want to use the Windows port instead: 
https://docs.webkit.org/Ports/WindowsPort.html


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] WebKitGTK 2.43.4 released

[Michael Catanzaro]

One more notable change is that JPEG 2000 support and the dependency on 
OpenJPEG has been removed.



___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Disable pinch zoom on webview

[Michael Catanzaro]

I asked around and have been told it's not possible to disable this.

We currently have 
webkit_settings_get/set_enable_back_forward_navigation_gestures(), so I 
think it would make sense to also have a 
webkit_settings_get/set_enable_pinch_zoom_gesture() as well


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] WebKitGTK 2.43.2 released

[Michael Catanzaro]

Hi all,

Heads-up: this release removes the dependency on libwpe and 
wpebackend-fdo!


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] No flag for WebGPU - is it planned?

[Michael Catanzaro]

Hi, I have no clue, sorry. Maybe somebody more familiar with graphics 
and WebGPU could answer.



___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] No flag for WebGPU - is it planned?

[Michael Catanzaro]

Hi Andrea,

WebGPU is not supported and nobody is working on it, so I assume it's 
also not planned. Sorry.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

[webkit-gtk] GLES is now required

[Michael Catanzaro]

Hi distributors,

WebKitGTK 2.42 now always uses GLES in the web process; previously, it 
could use either desktop GL or GLES, and would generally have been 
using GL in most Linux distros. (The UI process will use either GL or 
GLES depending on which is used by GTK itself.)


Please make sure your WebKitGTK packages have a runtime dependency on 
libGLESv2 or libepoxy will crash [1].


Thanks!

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2240428


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Fixing CVE-2023-41993

[Michael Catanzaro]

On Sun, Sep 24 2023 at 10:49:16 AM -0500, Douglas R. Reno 
 wrote:
Looking at this, I was wondering if we should patch it locally, or if 
there's going to be a new release of WebKit soon to fix this problem. 
Building WebKit takes a long time for us, so we'd prefer to not 
duplicate work if there's a new one coming in the next day or two.


Hi, there will indeed be a new release later this week.

Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Fix CVE-2023-32435 for webkitgtk 2.38.6

[Michael Catanzaro]

On Thu, Sep 7 2023 at 11:29:58 AM +0800, 不会弹吉他的KK 
 wrote:
For Yocto project whick I am working on, packages(recipes) can NOT be 
updated with
major version upgrade on Yocto released products/branches. So we 
still have to fix such
kind of CVEs. But for master branch, webkitgtk will be upgraded as 
soon as it released.


I'm going to recommend a different approach: don't fix any CVEs and 
instead prominently document that the version of WebKitGTK distributed 
by Yocto does not receive security updates. It's really better to avoid 
misplaced expectations; when you backport security fixes, people assume 
incorrectly that the package is receiving comprehensive security 
backports and is safe to use, but that's just not true. i.e. your 
security updates actually harm security because they mess up users' 
expectations. It's better to just be clear about it. We have this same 
problem in RHEL and are slowly moving towards doing no updates there as 
well.


I would recommend removing WebKitGTK and its dependencies from Yocto 
altogether if they have rules that prohibit you from releasing proper 
security updates just because the version number is higher. Anyway, 
good luck.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Fix CVE-2023-32435 for webkitgtk 2.38.6

[Michael Catanzaro]

On Wed, Sep 6 2023 at 04:23:17 PM +0800, 不会弹吉他的KK 
 wrote:

My question is
1. Does webkitgtk 2.38.6 is vulnerable to CVE-2023-32435?


No clue, sorry.

2. If YES, how to deal the patches with the 2 new files? If just 
ignore and only patch file 
Source/JavaScriptCore/wasm/WasmSectionParser.cpp, could 
CVE-2023-32435 be fixed for 2.38.6, please?


Patching just that one file is what I would do if tasked with 
backporting this fix. That said, keep in mind that only 10-20% of our 
security vulnerabilities receive CVEs, so just patching CVEs is not 
sufficient to provide a secure version of WebKitGTK. The 2.38 branch is 
no longer secure and you should try upgrading to 2.42. (I would skip 
2.40 at this point, since that branch will end next week when 2.42.0 is 
released.)


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Webkit bugzilla ID access

[Michael Catanzaro]

Hi, see: https://commits.webkit.org/260455@main


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] libwebkit2gtk and gstreamer-plugins dependencies

[Michael Catanzaro]

On Sat, Aug 12 2023 at 11:26:05 AM +0200, Fourhundred Thecat 
<400the...@gmx.ch> wrote:
Since I don't intend to use liferea for anything more than to read 
RSS,
I am wondering if it would be possible to reduce the number of 
dependent
packages, and perhaps compile libwebkit2gtk without all the media 
plugins ?


Yes, you can build with -DENABLE_VIDEO=OFF -DENABLE_WEB_AUDIO=OFF. (But 
major Linux distros are not going to do this.)



___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] [Q] block all network accesses – how?

[Michael Catanzaro]

Another problem is that HTTP requests are probably not the only way 
that network usage can happen, e.g. WebRTC or WebSockets presumably 
won't go through send-request. Not sure what to do about that.


On Wed, Aug 2 2023 at 06:46:04 PM +, Albrecht Dreß 
 wrote:
Please excuse my imprecise description – I *do* actually catch this 
signal in my extension.  The handler is connected in the 
WebExtension::page-created callback via


	g_signal_connect(web_page, "send-request", 
G_CALLBACK(send_request_cb), NULL);


and the latter callback changes the request URI to

webkit_uri_request_set_uri(request, "about:blank");


It's probably better to return TRUE to block the request.

unless the uri is already “about:blank” or starts with “cid:” 
or “data:”.  A debug message indicates that the signal is caught, 
and tcpdump doesn't show the http request, so I /think/ this part 
works as expected.


To me, this behavior looks as if the WebKitWebPage::send-request 
signal is fired only /after/ the connect() to the target host, but 
before the send(), which would perfectly explain my observations.


That would be really weird and certainly not how it's supposed to work, 
but I've seen stranger bugs



If that doesn't work, it's probably a bug.


I see… so I should create a bug report in bugzilla?


Yes, if the problem still occurs after changing your code to return 
TRUE (likely), then please do. The simpler your reproducer, the better 
chance of it getting fixed.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] [Q] block all network accesses – how?

[Michael Catanzaro]

On Wed, Aug 2 2023 at 04:47:47 PM +, Albrecht Dreß 
 wrote:
I use WebKitGtk in a MUA, which for privacy reasons shall block all 
external network accesses unless the user explicitly allows them.  
Using a web extension, I could redirect these accesses to 
“about:blank”.  However, I /still/ see webkit opening tcp 
connections to the remote sites, which IMHO shouldn't happen, as it 
already leaks information to a potential attacker.


You should be able to use the WebKitWebPage::send-request signal to 
block all network requests. If that doesn't work, it's probably a bug.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Webkit bugzilla ID access

[Michael Catanzaro]

On Wed, May 31 2023 at 05:13:48 AM +, "Urade, Yogita" 
 wrote:

And there are more than 15 CVE issues for 2.36.8 till now.


BTW, I just noticed this: I actually count 25 CVEs fixed since 2.36.8. 
Please see https://webkitgtk.org/security.html for a list of CVEs.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Webkit bugzilla ID access

[Michael Catanzaro]

Hi, the bugs are private. I can give you the mappings between bug ID 
and fix commit, though:


248266 - https://commits.webkit.org/258113@main
245521 - https://commits.webkit.org/256215@main
245466 - https://commits.webkit.org/255368@main
247420 - https://commits.webkit.org/256519@main
246669 - https://commits.webkit.org/255960@main
248615 - https://commits.webkit.org/262352@main
250837 - https://commits.webkit.org/260006@main

That said, I don't generally recommend backporting fixes yourself 
because (a) it can become pretty difficult as time goes on, and (b) 
only a tiny fraction of security fixes receive CVE identifiers (maybe 
around 5%). So I highly recommend upgrading to WebKitGTK 2.40.2. 
WebKitGTK maintains API and ABI stability to the greatest extent 
possible in order to encourage safe updates.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] glib-mkenums and preprocessor conditionals

[Michael Catanzaro]

The preprocessor guards are supposed to be stripped out by unifdef. Is 
something going wrong with your unifdef?



___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] How to fix CVEs of webkitgtk 2.36.x

[Michael Catanzaro]

On Wed, Mar 22 2023 at 11:26:56 AM +0200, Adrian Perez de Castro 
 wrote:
Recently advisories published by Apple include the Bugzilla issue 
numbers
(e.g. [1]), so with some work you can find out which commits 
correspond to

the fixes.


It finally occurs to me that since Apple now publishes the bug 
information, we could start publishing revision information. We'd want 
to fix [1] first.


WebKitGTK 2.38.x is backwards compatible with 2.36.x, you can safely 
update
without needing to change applications. In general, we always keep 
the API and

ABI backwards compatible.


For avoidance of doubt, WebKitGTK 2.40.x is backwards-compatible as 
well and that will remain true indefinitely, as long as you continue to 
build the same API version [2]. Adrian might be planning one last 
2.38.x release, but it's really time to move on to 2.40.


On rare occasions, an upgrade might affect the behavior of particular 
API functionality within the same API version, but this is unusual and 
is avoided whenever possible. I don't think any APIs broke between 2.36 
and 2.40, so that shouldn't be a problem for you this time. The goal is 
for upgrades to be as safe as possible.


Michael

[1] https://bugs.webkit.org/show_bug.cgi?id=249672
[2] 
https://blogs.gnome.org/mcatanzaro/2023/03/21/webkitgtk-api-for-gtk-4-is-now-stable/



___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] WebKitGTK 2.39.91 released

[Michael Catanzaro]

Hi again,

There are now actually two required patches:

https://github.com/WebKit/WebKit/pull/11221
https://github.com/WebKit/WebKit/pull/11222

Sorry for the trouble!


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] WebKitGTK 2.39.91 released

[Michael Catanzaro]

Hi all,

To build for GTK 4, you'll need to use this small patch:

https://github.com/WebKit/WebKit/pull/11221


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] WebKitGTK 2.39.90 released

[Michael Catanzaro]

Hi all, to build applications that use WebKitGTK 2.39.90, you'll need 
to include the patch from here:


https://github.com/WebKit/WebKit/pull/10362


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] window.webkit undefined?

[Michael Catanzaro]

On Wed, Jan 25 2023 at 06:37:11 PM +0100, Antonio  
wrote:
The fact is that I'm trying to receive messages from a 

[webkit-gtk] WebKitGTK soname bump season

[Michael Catanzaro]

Hi,

The webkitgtk-6.0 API (for GTK 4, not GTK 3) will be doing several 
soname bumps over the next month or so in preparation for stabilizing 
the GTK 4 API. The first has occurred already in 2.39.5 and there will 
be more in the upcoming unstable releases. Packages, please take note 
and prepare rebuilds of dependent packages as required. Known affected 
packages are currently epiphany, evolution-data-server, gnome-builder, 
and gnome-initial-setup. (And note that gnome-initial-setup itself 
transitively depends on evolution-data-server, so order will matter.)


Sometime soon, hopefully in February but maybe early March, the API/ABI 
will become stable, as it already is for GTK 3, and the pain will be 
over. Hopefully.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Performance issue for some https urls

[Michael Catanzaro]

On Thu, Jan 19 2023 at 09:51:49 AM +0100, Antonio  
wrote:
I think I'll create a bug report. Is there any way I can add some 
profiling information to the bug report with the MiniBrowser? (using 
environment variables or similar?).


Not easily, unfortunately.


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Performance issue for some https urls

[Michael Catanzaro]

On Wed, Jan 18 2023 at 09:49:34 PM +0100, Antonio  
wrote:

1.- Is this a bug or a feature?


A 12-second delay is certainly not good, but why do you suspect the 
performance problems you've found have anything to do with certificate 
validation? That should happen more or less instantaneously. And if 
DigiCert were not trusted (it surely is) then the page would not load 
at all. So I suspect something unrelated is wrong.


Since you're investigating a performance problem, be sure to use 
webkit2gtk-4.1 (libsoup 3, HTTP/2) and not webkit2gtk-4.0 (libsoup 2, 
HTTP/1.1), although it shouldn't make *that* big of a difference.



2.- Does WebKitGTK use the system CA trustore or an embedded one?


On Ubuntu and most Linux distros, it will use the system trust.


3.- How can I can specify a custom CA truststore in my WebKitGTK app?


You cannot, sorry. API users do not have this level of control over the 
network process.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

[webkit-gtk] Patches for WebKitGTK 2.39.4

[Michael Catanzaro]

Hi all,

If you are building WebKitGTK 2.39.4 for GTK 3, you'll need to use the 
following two patches to avoid installing broken public headers:


https://github.com/WebKit/WebKit/commit/9fe47e98a7f3b542413f3793912b291599f05860.patch
https://github.com/WebKit/WebKit/commit/8f11ad0813c37f4bd8ee43ecac733892a57e2a03.patch

Thanks to Thomas Devoogdt for fixing these issues.

Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] How to enable or disable hardware acceleration ?

[Michael Catanzaro]

On Sat, Jan 7 2023 at 09:05:06 PM +0800, 406643764 <406643...@qq.com> 
wrote:

So how to enable or disable hardware acceleration ?


Hi, use webkit_settings_set_hardware_acceleration_policy().

You can also use WEBKIT_FORCE_COMPOSITING_MODE=1 or 
WEBKIT_DISABLE_COMPOSITING_MODE=1 for test purposes.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Nothing shown in the widget when compiling with Fedora 37

[Michael Catanzaro]

Hi Lothar,

afaik the GTK 4 version of WebKitGTK (which you built here) has never 
supported NVIDIA.


Epiphany in Fedora 37 uses the GTK 3 version of WebKitGTK, so if 
something's wrong there, it's a separate problem.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Understanding WebKitGTK sources

[Michael Catanzaro]

On Sat, Dec 17 2022 at 07:57:25 PM +0200, André A. Gomes 
 wrote:

Hi,

I don't understand how WebKitGTK sources are generated.  I see that 
the

file structure resembles that of WebKit git sources hosted on GitHub.

Is there are a repository where WebKitGTK lives?


It is developed in https://github.com/WebKit/WebKit/


 Is there a script or a
manual procedure that transforms WebKit sources into WebKitGTK 
sources?




Hi, the tarballs are generated using this script:

https://github.com/WebKit/WebKit/blob/main/Tools/Scripts/make-dist

And this manifest:

https://github.com/WebKit/WebKit/blob/main/Tools/gtk/manifest.txt.in






___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] web process crashing on launch

[Michael Catanzaro]

On Mon, Aug 22 2022 at 11:08:48 AM +, "Subramani, Prasanth" 
 wrote:

processDidTerminateOrFailedToLaunch: reason=4


Unfortunately that's ProcessTerminationReason::Unresponsive, which just 
means the web process is not replying to the UI process, so the UI 
process decided to kill it. Since it's not crashing, it's going to be 
pretty tough to debug. You can try attaching to the web process with 
gdb and take a few backtraces to see what it's doing. If you're lucky, 
then maybe the backtrace will show something interesting. But if it's 
just polling doing nothing, it could be very tough to figure out what's 
wrong.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] WebKitGTK 2.37.1 released!

[Michael Catanzaro]

Hi all,

This release should build successfully on both x86_64 and aarch64, but 
for most other architectures you will need to apply this patch:


https://github.com/WebKit/WebKit/commit/40e49bb53218a986b4d6569f3fc2730cc4b71472.patch

Hope that helps,

Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] [PSA] Release branches moving to Git/GitHub

[Michael Catanzaro]

On Tue, Jul 5 2022 at 11:37:10 AM +0200, Adrian Perez de Castro 
 wrote:

We may look into creating Git tags for older releases at some point,
once we have migrated the missing older branches.


Tags are valuable.

Thanks for handling this migration!


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Failed to compile WebKitGTK 2.36.3

[Michael Catanzaro]

You are missing wayland-protocols (dev/devel subpackage, if your distro 
uses devel packages).


Your build should have failed at the CMake stage, at the very start, 
not after it gets to 93%. Feel free to report a bug to complain about 
this.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] WebkitGtk 2.26.0 WebKitWebView fails to display in a Gtk3 app.

[Michael Catanzaro]

Unrelated tip: change "--socket=x11" to "--socket=fallback-x11" to 
allow flatpak to block X11 access unless the host environment is 
actually X11. "--socket=x11" should only be needed for apps that don't 
support Wayland.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] WebkitGtk 2.26.0 WebKitWebView fails to display in a Gtk3 app.

[Michael Catanzaro]

Hi, the default hardware acceleration policy changed from 
WEBKIT_HARDWARE_ACCELERATION_POLICY_ON_DEMAND to 
WEBKIT_HARDWARE_ACCELERATION_POLICY_ALWAYS. I think you need to add 
"--device=dri" to the finish-args in your flatpak-builder manifest:


https://github.com/flathub/org.gnucash.GnuCash/blob/master/org.gnucash.GnuCash.json

so try that. If that fixes it, let us know and I'll post an 
announcement to remind other maintainers.


Alternatively, you could use 
webkit_settings_set_hardware_acceleration_policy() to select 
WEBKIT_HARDWARE_ACCELERATION_POLICY_NEVER to disable GPU usage. This 
option will go away with GTK 4 though -- WebKitGTK will always require 
GPU -- so probably better to leave it enabled and shake out any 
problems now.


Hope that helps,

Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Build for GTK+2 with gcc 11.2

[Michael Catanzaro]

On Wed, Feb 23 2022 at 11:09:46 AM +, Frederick Virchanza Gotham 
 wrote:

I tried patching a file here and there in webkitgtk-2.4.11 but the
list of compiler errors gets longer. Should I just use gcc version
4.9.4 (released in August 2016) to build webkitgtk-2.4.11 statically
linked with the C++ standard library (i.e. link it with the flag
-static-stdc++), and then switch back to gcc 11.2 to build everything
else?


I wouldn't expect a static build to work at all, but certainly using an 
older compiler seems more likely to be successful. You're on your own 
going back this old... good luck.


I would encourage you to not use this build of WebKit to process any 
web content that you did not create yourself.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] R: Re: R: Re: Can't find a way to implement content blocking (filtering)

[Michael Catanzaro]

On Tue, May 18 2021 at 07:08:21 AM +0200, linux...@tin.it wrote:

It doesn't matter where the callbacks are,
they are called synchronously and, when invoked, they run in the 


thread, even if they were declared in what "seems" the  (or UI)
thread.


Hi,

(Beware: none of  WebKitGTK's APIs are threadsafe. They can only be 
used on the GTK thread, which is almost always your main thread.)


The concern isn't threads, it's process boundaries. IPC between 
processes is fine, but synchronous IPC that blocks the entire web 
process is not. Synchronous IPC between processes must be kept to a 
bare minimum. It's should be possible to design a send-request API that 
only blocks network loads in the web process, and does not the entire 
web process, but I guess that's probably not how it works internally 
today, so would likely need some work to make it happen. (I'm just 
guessing: I haven't actually looked at the code.) This is one of those 
"patches welcome" things I'm afraid, and changing it would probably be 
a lot harder than writing your web process extension was. :)



Anyway, that
is gone. Now I am fighting with the find_controller which doesn't seem
to work, not even in the already-compiled MiniBrowser application that
I received bundled with the webkit2gtk library (libwebkit2gtk-4.0.so.
37.49.9 on a Debian stable). I will investigate more, but it seems
there is something wrong in the library itself.


Good luck!

Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] R: Re: Can't find a way to implement content blocking (filtering)

[Michael Catanzaro]

On Tue, May 4 2021 at 06:53:58 PM +0200, linux...@tin.it wrote:

Ok, let's see... any idea on how to make the UI (main program)
communicate with the library? A pipe perhaps?


A pipe would work. You can use whatever form of IPC you want. But there 
are a few built-in options that will probably be easier:


UI process -> web process:

webkit_web_context_send_message_to_all_extensions()
webkit_web_view_send_message_to_page()

Web process -> UI process:

webkit_web_extension_send_message_to_context()
webkit_web_page_send_message_to_view()


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Can't find a way to implement content blocking (filtering)

[Michael Catanzaro]

On Tue, May 4 2021 at 08:07:00 AM +0200, linux...@tin.it wrote:

I noticed that there is a very similar signal also in
webkit, but to use it one has to use an extension which, it seems to
me, has to be an external library. Even if I could try to write and
compile a similar library, then the dialog between the library and the
main application would be quite complicated, I think.


This is the only way to do it. You need to use the 
WebKitWebPage::send-request signal. Return TRUE to cancel the resource 
load, or FALSE to continue the load. WebKitWebPage is a web process 
object: you wouldn't want this API in the UI process because then the 
web process to have to wait on IPC to the UI process for every single 
resource to be loaded.


Writing a web process extension is easy, don't worry. Especially so 
when you only have one signal to implement. There are plenty of 
examples out there, e.g.:


https://gitlab.gnome.org/GNOME/epiphany/-/blob/6be2365125f7c3710635aabb1aeed420df5d84c7/embed/web-process-extension/ephy-web-process-extension.c.

Except your extension will be much simpler than that. You connect to 
WebKitWebExtension::page-created in your 
WebKitWebKitensionInitializeFunction, and in your page-created callback 
you can connect to WebKitWebPage::send-request. And that's about it.


Compiling it into a shared object is easy too, e.g.:

https://gitlab.gnome.org/GNOME/epiphany/-/blob/6be2365125f7c3710635aabb1aeed420df5d84c7/embed/web-process-extension/meson.build#L23

Good luck,

Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] [webkit-dev] Plugin process

[Michael Catanzaro]

On Mon, Jul 20, 2020 at 9:35 am, Michael Catanzaro 
 wrote:
For now, I'll submit a patch to deprecate these settings without 
changing behavior yet.


Meh, I did this, but realized that it's easier to write deprecation 
messages when we remove support for the feature at the same time that 
it's deprecated. That is, if we wait until after branching to 
deprecate, we can write:


Deprecated: 2.32: NPAPI browser plugins are insecure and no longer 
supported.


Rather than:

Deprecated: 2.30: NPAPI browser plugins are insecure and will no longer 
be supported in 2.32.


And then later changing it to:

Deprecated: 2.30: NPAPI browser plugins are insecure and no longer 
supported since 2.32.


So let's wait until branching.


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] [webkit-dev] Plugin process

[Michael Catanzaro]

On Mon, Jul 20, 2020 at 11:47 am, Adrian Perez de Castro 
 wrote:
Our tentative plan for sunsetting the NPAPI support is to keep 
supporting
the GTK3 plugin process in the next stable release series. This means 
that
we could remove the support from trunk after creating the stable 
branch

for the 2.30.x releases—that would be around September-October 2020.


Well branching normally occurs in August... just a few weeks away now. 
Then we can make the plugin process specific to PLATFORM(COCOA), until 
Apple figures out if it can be removed, and we can delete the support 
for all other platforms.


For now, I'll submit a patch to deprecate these settings without 
changing behavior yet.


I think we would need to make the public API to toggle the support 
for plugins

a no-op and log a warning to avoid breaking applications.


Well a warning certainly doesn't hurt. I suspect no applications are 
using it, though.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Follow-up on Support for PKCS11/Smartcard

[Michael Catanzaro]

On Mon, Jul 22, 2019 at 9:00 AM, Michael Catanzaro 
 wrote:
Yes. :) And also in WebKit. One of our developers has been 
investigating it recently for a potential project. If approved, then 
we'll revive that code but integrate it into the main backend so that 
it's actually enabled for users for the first time. But the customer 
is moving slowly and approval isn't certain yet. I'll try to remember 
to mention any outcome here in a few months.


https://gitlab.gnome.org/GNOME/glib-networking/merge_requests/65


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Follow-up on Support for PKCS11/Smartcard

[Michael Catanzaro]

On Mon, Jul 22, 2019 at 6:10 AM, Benjamin Greiner 
 wrote:

Are you sure you have to implement it in glib-networking?


Yes. :) And also in WebKit. One of our developers has been 
investigating it recently for a potential project. If approved, then 
we'll revive that code but integrate it into the main backend so that 
it's actually enabled for users for the first time. But the customer is 
moving slowly and approval isn't certain yet. I'll try to remember to 
mention any outcome here in a few months.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Follow-up on Support for PKCS11/Smartcard

[Michael Catanzaro]

On Sun, Jul 21, 2019 at 1:48 PM, "Sindlinger, Randall A. 
(GSFC-619.0)[SCIENCE SYSTEMS AND APPLICATIONS INC]" 
 wrote:

Can you provide any further guidance or suggestions?


Hi Randall,

As described in the previous thread, WebKitGTK does not currently 
support smartcards. Sorry. This would require first adding smartcard 
support to glib-networking. There's been some interest in this, so 
maybe it will be implemented in the not-too distant future.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Next browser: Random (?) blank views when switching web view in GTK container

[Michael Catanzaro]

On Sat, Jul 6, 2019 at 8:46 AM, Pierre Neidhardt  
wrote:

Can you specify what is not being done by two many applications?
The gtk_box juggling?


Yeah.


Then how are we supposed to switch webview?


Well what you're doing looks right, it's just not something other 
applications do.


On Sat, Jul 6, 2019 at 8:46 AM, Pierre Neidhardt  
wrote:

WEBKIT_FORCE_COMPOSITING_MODE=1 always works, so I guess the issue is
with the transition.


Indeed, now you have enough for a bug report on WebKit Bugzilla, 
WebKitGTK component. And a second bug report for the crash you 
discovered.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Next browser: Random (?) blank views when switching web view in GTK container

[Michael Catanzaro]

On Sat, Jul 6, 2019 at 7:38 AM, Pierre Neidhardt  
wrote:
I first remove the old buffer webview from the gtk_box, then add the 
new

one.

Is this a broken way to do it?  Do I need to refresh or synchronize 
something?

Is it OK to display a web view in a gtk_box?


It's supposed to be OK, but probably not many applications do this, so 
not too surprising that there is a bug.


My first suspicion is that the problem might involve accelerated 
compositing mode, especially if the issue often occurs on GitHub and 
GitLab but not other websites. First step would be to test to confirm 
by running under the WEBKIT_FORCE_COMPOSITING_MODE=1 and the 
WEBKIT_DISABLE_COMPOSITING_MODE=1 environment variables (separately). 
With AC mode forced your bug should occur regardless of website (or, 
less-likely, never occur if the bug is caused by transitioning in and 
out of AC mode), and with AC mode disabled then the bug should never 
occur. Knowing whether this problem is related to AC mode is the first 
step.


You can also use webkit_settings_set_hardware_acceleration_policy(), 
but environment variables are easier for testing.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] TextCodec.cpp lacks include when compiling with clang-7.0

[Michael Catanzaro]

On Mon, Jun 24, 2019 at 12:49 AM, Denis Pronin  
wrote:
Hi, Michael. Thank you. Where can I take 2.24.3? I cannot see it in 
releases https://webkitgtk.org/releases/


Well it hasn't been released yet. Wait a few weeks!


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] TextCodec.cpp lacks include when compiling with clang-7.0

[Michael Catanzaro]

On Sun, Jun 23, 2019 at 7:26 PM, Michael Catanzaro 
 wrote:
Sure, I'll make sure this makes it into 2.24.3. Of course Gentoo can 
just patch it in for the meantime.


Well Adrian had already backported this two weeks ago, so you should be 
good to go with 2.24.3. Assuming there are no other failures, of course.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] TextCodec.cpp lacks include when compiling with clang-7.0

[Michael Catanzaro]

On Sun, Jun 23, 2019 at 2:33 PM, Denis Pronin  wrote:

Adrian, hi

Do you remember my letting you know about compiler error in 
TextCodec.cpp when using clang + libc++ as utilities. I noticed you 
fix it in 2.25 versions of the 'webkit-gtk', great. But may I ask you 
to port it back in 2.24? I am gentoo developer and gnome community 
refuses to provide unstableversion of webkit-gtk. I don't expect any 
issues if you have included 'cstdio' in TextCodec.cpp,this is only 
the header file, it can be safely included without any bad 
consequences. May we port it to a stable version?


Thank you


Sure, I'll make sure this makes it into 2.24.3. Of course Gentoo can 
just patch it in for the meantime.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] TextCodec.cpp lacks include when compiling with clang-7.0

[Michael Catanzaro]

On Tue, May 21, 2019 at 6:36 PM, Adrian Perez de Castro 
 wrote:
I just completed a build here with Clang 8.0 and it went just fine. I 
would
like to know whether you were using libc++ instead of libstdc++ 
before I try
to install Clang 7.1.0 to see if I can reproduce the issue. Could you 
comment

on that, please? (and thanks!)


If you fix this, remember it would be better to #include  
rather than #include  because that file uses ::snprintf, not 
std::snprintf.



___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

[webkit-gtk] WebKitGTK and WPE WebKit Security Advisory WSA-2019-0003

[Michael Catanzaro]

WebKitGTK and WPE WebKit Security Advisory WSA-2019-0003


Date reported : May 20, 2019
Advisory ID : WSA-2019-0003
WebKitGTK Advisory URL : 
https://webkitgtk.org/security/WSA-2019-0003.html
WPE WebKit Advisory URL : 
https://wpewebkit.org/security/WSA-2019-0003.html

CVE identifiers : CVE-2019-6237, CVE-2019-8571, CVE-2019-8583,
 CVE-2019-8584, CVE-2019-8586, CVE-2019-8587,
 CVE-2019-8594, CVE-2019-8595, CVE-2019-8596,
 CVE-2019-8597, CVE-2019-8601, CVE-2019-8607,
 CVE-2019-8608, CVE-2019-8609, CVE-2019-8610,
 CVE-2019-8615, CVE-2019-8611, CVE-2019-8619,
 CVE-2019-8622, CVE-2019-8623.

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 

Re: [webkit-gtk] Unable to build dependencies for webkitgtk on raspbian

[Michael Catanzaro]

On Wed, May 8, 2019 at 7:41 PM, Arvind Arvind Pro 
 wrote:
The problem is not that I want to remove some features- I want to 
build Webkit GTK with all its features intact- but how will that 
happen when some packages are not there in Debian Stretch? (Only  in 
Sid or Buster)?


You'll need to build those dependencies yourself, or use a newer OS. 
Debian Stretch is old and it's going to be impossible to build WebKit 
with all features enabled there unless you build many of the 
dependencies (e.g. GStreamer) yourself. For the official Debian builds, 
features that require newer versions of dependencies (e.g. media source 
extensions, needed for YouTube to work well) are simply disabled.


I think Buster should be new enough for you to do a full-featured build.

Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Unable to build dependencies for webkitgtk on raspbian

[Michael Catanzaro]

On Wed, May 8, 2019 at 8:11 PM, Arvind Arvind Pro 
 wrote:
The command cannot run in the code in the release tarball because 
there is no folder "Scripts" within it. Hence  the code from SVN is 
required.


Didn't you see the bold instructions on that page warning you these 
instructions are unsafe except for development builds? Is there 
something we could do to make it more clear?


The following steps are suitable for WebKit development only, not for 
production builds. Our JHBuild moduleset does not receive security or 
bugfix updates and it is not suitable for any purpose other than 
development and running layout tests. Do not run against untrusted 
websites.


The instructions for building releases are at the top of the page, 
above the instructions for development builds.


Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Printing from Flatpak not working

[Michael Catanzaro]

On Mon, May 6, 2019 at 6:39 AM, Michael Gratton  wrote:
Yup, but support for that landed in both the portal and GTK ages ago. 
If you're using GtkPrintOperation per the docs[0] it will Just 
Work™, but WebKitGTK has its own WebKitPrintOperation class 
(presumably to support the renderer being out of process) which 
doesn't seem to derive from it.


I don't think there's going to be any way to work around this simpler 
than just fixing the bug. It might require that we use the portal D-Bus 
API directly in WebKitPrintOperation.


Other things that are still broken in flatpak:

* Battery status (timers are never throttled, WebKit will eat your 
battery)

* Desktop notifications

Michael


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

[webkit-gtk] WebKitGTK and WPE WebKit Security Advisory WSA-2019-0002

[Michael Catanzaro]

WebKitGTK and WPE WebKit Security Advisory WSA-2019-0002


Date reported : April 10, 2019
Advisory ID : WSA-2019-0002
WebKitGTK Advisory URL : 
https://webkitgtk.org/security/WSA-2019-0002.html
WPE WebKit Advisory URL : 
https://wpewebkit.org/security/WSA-2019-0002.html

CVE identifiers : CVE-2019-6201, CVE-2019-6251, CVE-2019-7285,
 CVE-2019-7292, CVE-2019-8503, CVE-2019-8506,
 CVE-2019-8515, CVE-2019-8518, CVE-2019-8523,
 CVE-2019-8524, CVE-2019-8535, CVE-2019-8536,
 CVE-2019-8544, CVE-2019-8551, CVE-2019-8558,
 CVE-2019-8559, CVE-2019-8563, CVE-2019-11070.

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 

Re: [webkit-gtk] How to get a snapshot of an unmaped WebView ?

[Michael Catanzaro]

On Mon, Mar 18, 2019 at 10:44 AM, =?iso-8859-1?q?C=E9dric?= Bellegarde 
 wrote:
My question is: What is the correct way to get a snapshot of an 
unmapped webview?


I think it's just broken.


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Webkit2 signals/callbacks

[Michael Catanzaro]

On Wed, Feb 13, 2019 at 7:11 AM, Daniel Berek  
wrote:
Thanks. One last question: how can I execute external javascripts ( 
or jquery) which are linked in a html as 

Re: [webkit-gtk] Webkit2 signals/callbacks

[Michael Catanzaro]

On Tue, Feb 12, 2019 at 1:35 AM, Daniel Berek  
wrote:
Thanks it really works. But I still have to figure out how to pass 
data to my core class through webview widget - gtk:window - 
gui thread - core app. A simple function call freezes the gui, so 
some kind of in-build signal handling is needed. (in the other 
direction I have already managed by glib:dispatcher). Any idea how to 
bring out the script messages? Thanks


Did you try using 
webkit_user_content_manager_register_script_message_handler() to 
register a message handler? Then your JS content can use 
window.webkit.messageHandlers..postMessage([value]) to send 
messages to the UI process, and you receive them by connecting to the 
script-message-received::foobar signal. That's what Adrian was trying 
to suggest.


Regarding thread safety, there is none: the entire WebKit API must only 
be used from the GUI thread (whatever thread is running 
gtk_application_run() or gtk_main(), recommended but not required to be 
your main thread). If you need to perform blocking operations on a 
secondary thread, you can run code back on the GUI thread using e.g. 
g_main_context_invoke() or g_idle_add().


GObject signals are not threadsafe. Only connect to them from the GUI 
thread.


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] WebKitGTK+ name

[Michael Catanzaro]

On Fri, Feb 8, 2019 at 2:42 PM, Lucas Forschler  
wrote:
No problem, shall I simply remove the ‘+’ from the bugzilla 
component name? Or is there another change you would prefer?

Lucas


I see no objections, so please go ahead. Thanks!

Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

[webkit-gtk] WebKitGTK+ and WPE WebKit Security Advisory WSA-2019-0001

[Michael Catanzaro]

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


Date reported : February 08, 2019
Advisory ID : WSA-2019-0001
WebKitGTK+ Advisory URL : 
https://webkitgtk.org/security/WSA-2019-0001.html
WPE WebKit Advisory URL : 
https://wpewebkit.org/security/WSA-2019-0001.html

CVE identifiers : CVE-2019-6212, CVE-2019-6215, CVE-2019-6216,
 CVE-2019-6217, CVE-2019-6226, CVE-2019-6227,
 CVE-2019-6229, CVE-2019-6233, CVE-2019-6234.

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/.

The WebKitGTK+ and WPE WebKit team,
February 08, 2019

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] WebKitGTK+ name

[Michael Catanzaro]

On Fri, Feb 8, 2019 at 2:42 PM, Lucas Forschler  
wrote:
No problem, shall I simply remove the ‘+’ from the bugzilla 
component name?


Yeah, but let's please wait until Monday to see if anybody objects to 
the name change. It should be uncontroversial, I suppose.



 Or is there another change you would prefer?


Nope, that should suffice.

Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] WebKitGTK+ name

[Michael Catanzaro]

On Fri, Feb 8, 2019 at 10:02 AM, Michael Catanzaro 
 wrote:

Hi,

The GTK+ project has been renamed to GTK. i.e. they've dropped the +.

Shall we rename WebKitGTK+ to WebKitGTK? I think so?

Michael


Here's the discussion:

https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg0.html

CC: Lucas, who just kindly renamed our Bugzilla product from "WebKit 
Gtk" to "WebKitGTK+". Seems it was bad timing. :P


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

[webkit-gtk] WebKitGTK+ name

[Michael Catanzaro]

Hi,

The GTK+ project has been renamed to GTK. i.e. they've dropped the +.

Shall we rename WebKitGTK+ to WebKitGTK? I think so?

Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Webkit2 signals/callbacks

[Michael Catanzaro]

On Tue, Feb 5, 2019 at 6:51 AM, Adrian Perez de Castro 
 wrote:
You can also use an injected JS script [1] which hooks into the 
“onclick”
events and send user script messages [2] to the process that is 
embedding

the Web view. Depending on your use case that might be good enough,


Uh yeah, that's way easier and almost certainly a better answer. Wasn't 
thinking yesterday I guess. :)


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Webkit2 signals/callbacks

[Michael Catanzaro]

On Mon, Feb 4, 2019 at 2:46 AM, Daniel Berek  
wrote:
Hi, is there any signal or callback for handling an "onClick" event 
in c++ program (similar to mouse-target-changed)?
Html sites are loaded with webkit_web_view_load_html() and my goal is 
to process user input, when HTML divs are clicked.
(or connect the html onClick event through javascriptcore with my 
code)

Does anybody have any solution for my problem? Thnaks, Daniel


You're going to need to do this in JavaScript, possibly in the web 
process using the web process extension API [1]. I don't have any 
simple examples, but [2] will at least get you started at running code 
in the web process, including the JavaScript under resources/js. Good 
luck!


Michael

[1] https://webkitgtk.org/reference/webkit2gtk/stable/ch02.html
[2] 
https://gitlab.gnome.org/GNOME/epiphany/tree/master/embed/web-extension


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] can't view comments on this blog

[Michael Catanzaro]

On Mon, Jan 28, 2019 at 6:56 AM, Dennis New  
wrote:

(I'm using 2.22.5)


Works for me in both 2.22.5 and 2.23.3.

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Silently failing to load web extensions

[Michael Catanzaro]

On Thu, Jan 17, 2019 at 7:04 PM, Michael Gratton  wrote:

So, how about that error reporting? ;)


I don't know. I think really the main way this could break is if you 
don't install the web extension into the web extensions directory at 
all. And that's easy enough to check in the application without having 
to add new WebKit API. Are you aware of other ways web extensions have 
broken in practice? That haven't led to CLI warnings (e.g. if a .so 
cannot be loaded, there would probably be a CLI warning from the 
dynamic linker anyway).


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Remote debugger broken after 2.23.2 upgrade

[Michael Catanzaro]

On Thu, Jan 17, 2019 at 2:17 PM, serban u  
wrote:

Hello,
It appears to me that Remote Debugger stopped working after upgrading 
to webkitgtk 2.23.2. I tried loading a web page inside minibrowser 
and I can attach to it, but I get no data at all, in any of the 
remote inspector tabs. Is this issue known? Should I report a ticket 
for it(considering that this is an unstable release) ?


Regards,
Serban Ungureanu


I would absolutely report a bug. Make sure to select the "Webkit Gtk" 
component on Bugzilla and prefix the title of the bug with "[GTK]". 
Thanks!


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Silently failing to load web extensions

[Michael Catanzaro]

On Thu, Jan 17, 2019 at 4:44 PM, Michael Gratton  wrote:

pkglibexecdir = join_paths(libexecdir, 'epiphany')
webextensionsdir = join_paths(pkglibdir, 'web-extensions')


pkglibdir, not pkglibexecdir! The variables are sorted alphabetically.

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Silently failing to load web extensions

[Michael Catanzaro]

On Wed, Jan 16, 2019 at 6:38 PM, Michael Gratton  wrote:

Hey all,

It looks like people who install Geary from source to /usr/local 
(more common now that meson defaults to that as the install prefix) 
are finding their web extensions not being loaded under Fedora for... 
reasons.


It would be good to have a more deterministic API for loading 
extensions, so applications can determine when loading one has failed 
and report an error, something like 
"webkit_web_context_load_web_extension_async(const gchar *dir, const 
gchar *name, ...)". Is this likely to be possible to implement?


Um... what are "reasons"? If Geary calls 
webkit_web_context_set_web_extensions_directory() with the correct 
directory then web extensions under /usr/local should work just fine.


As an aside, I note that Ephy is installing its web extensions to 
`libexec`, despite extensions not being executables. Is that to work 
around issues with /usr/local lib dirs not being on ld.so.conf paths?


No, Epiphany installs its web extension into libdir/epiphany. That's 
/usr/lib64/epiphany on Fedora. Where did you find it under libexec? Of 
course it doesn't belong there.


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Make unit tests buildable from tarballs

[Michael Catanzaro]

On Fri, Jan 11, 2019 at 3:43 AM, Tomas Popela  
wrote:
 * In CMAKE files the ENABLE_API_TESTS is guarded by the 
DEVELOPER_MODE
 * The tests itself depends on the WebKit C API, that is not exported 
in our shared library (it's filtered out by the 
webkitglib-symbols.map). The list of what symbols are needed is on 
the end of this mail.
 * Even if we add all the required C APIs to the map, then the 
compilation will the tests use private functions that are again not 
exported - e.g. the WebProcessTest uses 
webkitWebExtensionSetGarbageCollectOnPageDestroy() from 
Source/WebKit/WebProcess/InjectedBundle/API/glib/WebKitWebExtensionPrivate.h
 * To be able to run the tests from the builddir we would have to 
move functions or their parts like getExecutablePath(), 
findWebKitProcess() in 
Source/WebKit/Shared/glib/ProcessExecutablePathGLib.cpp and 
injectedBundleDirectory() in 
Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp outside of the 
DEVELOPER_MODE ifdefs.

 * It "probably" needs files that are not included in the tarball


I don't think we need a new libwebkit2gtktest library if we build 
separate static libs. Then the API tests could link against the static 
libs, and you'd have access to everything?


We could also internally build everything as static libs, and add 
shared libs linked to those at the end of the build?


Linking is hard. :( Our current status quo has a serious problem that 
all internal WTF and JSC and bmalloc symbols are public anyway, via 
libjavascriptcoregtk, where we can't hide internal symbols because it 
would break C++ templates used as global variables (like 
PerProcess).


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Loading images from file:// URL containing non-ASCII characters

[Michael Catanzaro]

On Fri, Jan 11, 2019 at 6:42 PM, Michael Catanzaro 
 wrote:
It sounds like a bug to me, especially since it works if all is 
ASCII. I think it's already reported on WebKit Bugzilla somewhere, 
but I couldn't find it with a quick search -- good luck finding 
anything on there -- so unless somebody has a link, might be best to 
report a new one.


Not sure if it's a coincidence, but somebody just found and bumped it:

https://bugs.webkit.org/show_bug.cgi?id=184660

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Loading images from file:// URL containing non-ASCII characters

[Michael Catanzaro]

On Thu, Jan 10, 2019 at 7:11 PM, Scott Talbert  wrote:
Is this a bug?  It would seem to me that it would be - I don't know 
why a file:// URL shouldn't be able to load other local resources.  
And it works with a file:// URL with all ASCII characters.


It sounds like a bug to me, especially since it works if all is ASCII. 
I think it's already reported on WebKit Bugzilla somewhere, but I 
couldn't find it with a quick search -- good luck finding anything on 
there -- so unless somebody has a link, might be best to report a new 
one.


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Support for PKCS11 / Smartcard?

[Michael Catanzaro]

On Thu, Dec 6, 2018 at 9:50 PM, mailto428496  
wrote:

Actually I was testing CentOS 7 in a VM with smartcard, so that will
work fine.


Still curious to hear the results of your testing on Fedora 29, to 
figure out whether the gnutls-pkcs11 backend was important!



Just curious, how are priorities set as to what functionality or code
changes are a priority vs another?  I am guessing it is based on the
priorities of the project supporting organizations (such as linux
vendors, etc.?).  But it sounds like I am one of the first to ask for
smartcards to work?  Given the push for smartcards across the 
government

I would have expected a lot of interest in stuff like this!


I just found another request:

https://gitlab.gnome.org/GNOME/epiphany/issues/414

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

[webkit-gtk] WebKitGTK+ and WPE WebKit Security Advisory WSA-2018-0009

[Michael Catanzaro]

WebKitGTK+ and WPE WebKit Security AdvisoryWSA-2018-0009


Date reported   : December 13, 2018
Advisory ID : WSA-2018-0009
WebKitGTK+ Advisory URL : 
https://webkitgtk.org/security/WSA-2018-0009.html
WPE WebKit Advisory URL : 
https://wpewebkit.org/security/WSA-2018-0009.html

CVE identifiers : CVE-2018-4437, CVE-2018-4438, CVE-2018-4441,
 CVE-2018-4442, CVE-2018-4443, CVE-2018-4464.

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/.

The WebKitGTK+ and WPE WebKit team,
December 13, 2018

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Support for PKCS11 / Smartcard?

[Michael Catanzaro]

On Thu, Dec 6, 2018 at 12:19 AM, mailto428496  
wrote:


I will have to see about setting up Fedora 29 in a VM to test.


I guess also try CentOS in a VM first, to make sure the smartcard is 
accessible to VMs.


 We just need to fix https://bugs.webkit.org/show_bug.cgi?id=164509. 
It

 shouldn't be too hard and it's on my TODO. I can't promise when I'll
 get to it, though.



Ok, do you have a ballpark on when you might have time to work on 
this?

Are we talking a few months, or a year or more?


Honestly no clue. Hopefully weeks or months.

Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Sockets/file descriptors and the web extension

[Michael Catanzaro]

WebKit uses several child processes. A WebKitWebExtension is just a way 
to run code in the WebKitWebProcess. Each WebKitWebView corresponds to 
one WebKitNetworkProcess and one or more WebKitWebProcess processes. 
These will be created regardless of whether or not you use the 
WebKitWebExtension class to inject code into the WebKitWebProcess 
processes.


On Wed, Dec 5, 2018 at 1:51 PM, Adrian Perez de Castro 
 wrote:
Are you setting the close-on-exec flag [1] on the file descriptor? If 
not,
it may be as well that the file descriptor for the socket is being 
inherited

by the child processes (WebKitNetworProcess, WebKitWebProcess, etc).


This should not be possible. WebKit creates subprocesses using 
g_spawn_async() in ProcessLauncherGLib.cpp. You can review the relevant 
code in GLib's gspawn.c. After forking, GLib iterates through all open 
file descriptors (except stdin, stdout, and stderr) and sets FD_CLOEXEC 
on each one to ensure they get closed when it later calls exec.


Otherwise, if Eclipse failed to set CLOEXEC itself, then the file 
descriptors would be leaked in the child process, and you would 
probably wind up with this socket in use or not available error. (This 
behavior can be disabled using the G_SPAWN_LEAVE_DESCRIPTORS_OPEN flag, 
but WebKit does not use this flag.)


So Eric, you say "debugging shows that the web extension still holds 
onto the socket/file descriptor." Are you sure the affected file 
descriptor is really owned by the WebKitWebProcess? If so, something 
very weird is happening inside gspawn.c, because it shouldn't be 
possible.


On a different note, from the brief description if the use case you 
gave on
your first e-mail, I think you can probably get things done without 
using

a WebKitWebExtension at all.


Yes, if it's possible to avoid the need for a WebKitWebExtension 
altogether, that would be ideal.


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Sockets/file descriptors and the web extension

[Michael Catanzaro]

On Wed, Dec 5, 2018 at 11:11 AM, Eric Williams  
wrote:
Some preliminary debugging shows that the web extension still holds 
onto the socket/file descriptor used when opening the port in step 1 
-- even though the port has been closed. This causes the error in 
step 4. If no web extension is created (i.e. step 2 is skipped), then 
no error from step 4 happens.


I'm confused and suspect I've misunderstood the scenario. But: why does 
WebKit have anything to do with a socket that you create in your own 
code?


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Support for PKCS11 / Smartcard?

[Michael Catanzaro]

On Mon, Dec 3, 2018 at 8:16 PM, mailto428496  
wrote:

Let me know if you have any ideas on how to test the glib-networking
without WebKit, I am just not sure what else smartcard auth related
would use it?


I hear it might have worked with a previous version of Evolution's 
Exchange support. My guess is this only ever worked in Evolution, but 
nowadays doesn't.


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Support for PKCS11 / Smartcard?

[Michael Catanzaro]

On Mon, Dec 3, 2018 at 8:16 PM, mailto428496  
wrote:

Michael,

As you predicted it didn't work for smartcard authentication with 
WebKit

(MiniBrowser) (perhaps I was overly optimistic that somehow it would
magically work ;) and I am not sure how else to test it?  But setting
the GIO_USE_TLS=gnutls-pkcs11 variable does cause it to start looking 
at
smartcard related libraries.  So that sounds like there is hope that 
it

would work after you got the client authentication working, that I
assume would interface with whatever gnutls-pkcs11 provided?  Any idea
when that might happen?  Also, it seems like it would be useful to 
leave

the pkcs11 code around that you had recently removed ;)


That's what we need to figure out. Maybe you could do the same thing 
with glib-networking 2.58 (e.g. in Fedora 29) and see if the smartcard 
libraries are still being used? I think it should still be used, just 
via GnuTLS rather than via gnutls-pkcs11. Not sure.



Let me know if you have any ideas on how to test the glib-networking
without WebKit, I am just not sure what else smartcard auth related
would use it?


I'll ask around and see if someone has ideas.

Also, this might be a long shot, but how hard would it be to get 
WebKit

to redirect to another browser like firefox that could do the auth, or
is the WebKit API just too specific for that to ever work?  For fun I
actually linked WebKitWebProcess to firefox and it does pop up 
firefox,

but not surprisingly none of the information gets passed.


Hehe, there's no way to make that work, indeed.

We just need to fix https://bugs.webkit.org/show_bug.cgi?id=164509. It 
shouldn't be too hard and it's on my TODO. I can't promise when I'll 
get to it, though.


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Support for PKCS11 / Smartcard?

[Michael Catanzaro]

I think won't work to authenticate you to the website, because WebKit 
doesn't (yet) support client authentication (that's on my TODO). So try 
to find some way to test it without using WebKit. Admittedly, that's a 
sticking point, because I'm really not sure how you would do that


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Support for PKCS11 / Smartcard?

[Michael Catanzaro]

On Sat, Dec 1, 2018 at 6:01 PM, mailto428496  
wrote:

I am testing this on CentOS 7 and it appears that the server cert ca
verification is working (we have the CA stores installed locally), at
least it doesn't complain that the site cert is invalid, but I suppose
it could just not be checking at all (which wouldn't be so great 
either...).


It definitely checks TLS certificates. That's only impressive if you 
have the server cert stored on your smartcard, though, which I assume 
is probably not what you're doing, right?


(Beware that the version of WebKit shipped by CentOS is always old and 
doesn't receive security updates.)



I think there would need to be an interface to the opensc or coolkey
libraries in order for it to access the smartcard.  It sounds like it 
is

a bit more complicated where there are multiple layers and packages
involved that would all need to support each other in order for this 
to

work.


I've never heard of these libraries before today, but I don't think so. 
From 
https://fedoraproject.org/wiki/Changes/Replace_Coolkey_with_OpenSC I 
gather that p11-kit wraps these libraries. And GnuTLS uses p11-kit as 
its default trust store (looks like since CentOS 7.3). Did you try 
GIO_USE_TLS=gnutls-pkcs11?



There has been discussion of contracting a developer to help with this
(if we can get funding, etc.) and if that happened I would hope that 
any
result could be contributed back to the open source community (but 
given

that it's the government that is another whole process).

I wanted to be sure that I wasn't missing something and that support 
was

not already included - which it sounds pretty clear that it isn't yet,
but maybe some of the groundwork is getting there?  And I wanted to 
get

an idea of what it might take to implement - which sounds non-trivial
but doable for someone willing to dig into the weeds and figure out 
how

all the pieces need to work together.


It's not clear to me at all. Until a couple months ago, we had tons of 
code for PKCS#11 in glib-networking. It didn't write itself for no 
reason. The problem is that I wound up inheriting all the code, without 
knowing if it's still important, or if anyone at all is using it with 
smartcards, and with nobody to test it or tell me if it's working, and 
every indication that it's obsoleted by GnuTLS-level support for 
PKCS#11, and with the code having never been enabled except behind a 
secret environment variable, I decided to delete it (in glib-networking 
2.58; you have 2.56 if you have CentOS 7.6). For the code to have 
remained, I needed someone interested to come forward and tell me that 
it was both working and also not redundant with the GnuTLS-level 
PKCS#11 support, and that didn't happen.


So set aside the WebKit-level client authentication issue, which will 
be solved soon regardless. Take WebKit out of the picture. We have 
support for PKCS#11 in GnuTLS. Your main concern right now is to make 
sure that the gnutls-pkcs11 backend I just removed from glib-networking 
is not important for you, because if so we just took a lot of steps 
backwards. That can be undone now far more easily than a e.g. year from 
now. So you want to be sure that glib-networking's gnutls backend can 
do everything the gnutls-pkcs11 backend could. In CentOS 7.6, you are 
in a good spot to do this, because you have glib-networking 2.56, which 
is the first version of glib-networking that uses GnuTLS's default 
trust store and also the last version that has the gnutls-pkcs11 
backend built by default. (In 2.58 it's disabled by default at build 
time. And in 2.60 it will be gone.)


Once TLS client authentication is working, there should be zero code in 
WebKit required to support smartcards. All of that code lives at the 
glib-networking and GnuTLS levels (and maaaybe libsoup, but I don't 
think so). So you can test whether this works today... just not using 
WebKit. (Not sure how exactly you would test it without WebKit, though. 
Without any support for client auth at the WebKit level, I'm really not 
sure what the code was written for.)


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Support for PKCS11 / Smartcard?

[Michael Catanzaro]

On Sat, Dec 1, 2018 at 11:14 AM, Michael Catanzaro 
 wrote:
It would need to be investigated by a developer with a smartcard and 
some interest in figuring out how it's supposed to work. You might 
know more than me! Did any of that make sense?


BTW to be clear:

* WebKit client auth is extremely likely to arrive sometime soonish. 
Shame it's not working quite yet.
* But once client auth is ready, smartcards may or may not work. No 
clue. There's a good chance they will, but it definitely won't be 
tested in WebKit, so maybe 50/50 odds, I really don't know.


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] Support for PKCS11 / Smartcard?

[Michael Catanzaro]

On Fri, Nov 30, 2018 at 8:41 PM, mailto428496  
wrote:

It does not appear that webkit-gtk has support for PKCS 11 and hence
smartcard devices, unless I am missing something...?  I was wondering 
if

there were any plans to implement this for webkit-gtk browsers?


Hm...

p11-kit is supported in Fedora, Arch, and any other distro that builds 
GnuTLS using --with-default-trust-store-pkcs11="pkcs11:". It won't work 
in Debian/Ubuntu/openSUSE or other distros that still use old-fashioned 
ca-certificate file storage. But in distros with p11-kit enabled, 
PKCS#11 assertions are supposed to be respected when performing server 
certificate verification.


But I don't know about smartcards. So the answer to that is: maybe? 
Maybe almost? WebKit doesn't currently support TLS client 
authentication at all, so my guess is not at the WebKit level. That's 
being actively worked on though, in 
https://bugs.webkit.org/show_bug.cgi?id=164509. (I know there's not 
much in the way of updates there, but it really is being worked on. :)


But that won't help if smartcards aren't working at the GLib level, and 
I'm not sure about the status there. I am quite certain that nobody 
working on this code has a smartcard or would know what to do with one, 
though. :( We used to have separate support in glib-networking for 
PKCS#11. I disabled it in 2.58 and recently deleted it entirely because 
nobody could tell me if it does anything that GnuTLS can't do itself 
nowadays. For details on that, see 
https://gitlab.gnome.org/GNOME/glib-networking/issues/7. Now, if you 
have an older version of glib-networking (2.56 or earlier) then you 
could try it out with the environment variable 
GIO_USE_TLS=gnutls-pkcs11, but remember that client authentication will 
not work in WebKit regardless, and I'm not sure what other apps you 
could use to test it. Anyway, my suspicion is that that code was not 
important, and that if any extra work is needed to make smartcards 
work, it should be done using the GnuTLS PKCS#11 APIs instead:


https://www.gnutls.org/manual/html_node/Smart-cards-and-HSMs.html

but really, I don't know. It would need to be investigated by a 
developer with a smartcard and some interest in figuring out how it's 
supposed to work. You might know more than me! Did any of that make 
sense?


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] GTK4

[Michael Catanzaro]

On Fri, Nov 23, 2018 at 11:46 AM, Andrea Giammarchi 
 wrote:
Out of curiosity, does that mean GTK4 doesn't bring interesting 
benefits so nobody cares about having a browser there?


From my perspective, we want this so that GNOME applications can be 
ported to GTK+ 4. But we have many more higher-priority tasks right 
now, so external help would be welcome.


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] GTK4

[Michael Catanzaro]

On Thu, Nov 22, 2018 at 12:12 PM, Eric Williams  
wrote:
I was wondering -- has work on a GTK4 port of WebKitGTK started? If 
not, what is the timeline for such work?


Hi Eric,

There is no work yet on this and it is not scheduled. I expect it would 
be a lot of effort to get working, and we're fully booked right now, 
and unfortunately none of our customers care about GTK+ 4 (it's a shame 
that Red Hat isn't a customer :) so it seems unlikely that we'd be able 
to start on this within the next year. Maybe.


If you want to help, I know Adrian Perez and Benjamin Otte have been 
throwing around some ideas. The plan involved writing a GTK+ 4 based 
libwpe backend so that the GTK port would become based on WPE. Adrian, 
this thread would be a good chance to document your ideas.


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

[webkit-gtk] WebKitGTK+ and WPE WebKit Security Advisory WSA-2018-0008

[Michael Catanzaro]

WebKitGTK+ and WPE WebKit Security AdvisoryWSA-2018-0008


Date reported   : November 21, 2018
Advisory ID : WSA-2018-0008
WebKitGTK+ Advisory URL : 
https://webkitgtk.org/security/WSA-2018-0008.html
WPE WebKit Advisory URL : 
https://wpewebkit.org/security/WSA-2018-0008.html

CVE identifiers : CVE-2018-4345, CVE-2018-4372, CVE-2018-4373,
 CVE-2018-4375, CVE-2018-4376, CVE-2018-4378,
 CVE-2018-4382, CVE-2018-4386, CVE-2018-4392,
 CVE-2018-4416.

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/.

The WebKitGTK+ and WPE WebKit team,
November 21, 2018

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

[webkit-gtk] WebKitGTK+ and WPE WebKit Security Advisory WSA-2018-0007

[Michael Catanzaro]

---
WebKitGTK+ and WPE WebKit Security AdvisoryWSA-2018-0007


Date reported   : September 26, 2018
Advisory ID : WSA-2018-0007
WebKitGTK+ Advisory URL : 
https://webkitgtk.org/security/WSA-2018-0007.html
WPE WebKit Advisory URL : 
https://wpewebkit.org/security/WSA-2018-0007.html

CVE identifiers : CVE-2018-4207, CVE-2018-4208, CVE-2018-4209,
 CVE-2018-4210, CVE-2018-4212, CVE-2018-4213,
 CVE-2018-4191, CVE-2018-4197, CVE-2018-4299,
 CVE-2018-4306, CVE-2018-4309, CVE-2018-4311,
 CVE-2018-4312, CVE-2018-4314, CVE-2018-4315,
 CVE-2018-4316, CVE-2018-4317, CVE-2018-4318,
 CVE-2018-4319, CVE-2018-4323, CVE-2018-4328,
 CVE-2018-4358, CVE-2018-4359, CVE-2018-4361.

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
   

Re: [webkit-gtk] Keyboard nav out of a WebView

[Michael Catanzaro]

On Thu, Sep 6, 2018 at 4:35 AM, Michael Gratton  wrote:
I've seen https://bugs.webkit.org/show_bug.cgi?id=157793, but is 
there any know work-around?


I can't think of any workaround. I think we just need to fix it.

Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

[webkit-gtk] WebKitGTK+ and WPE WebKit Security Advisory WSA-2018-0006

[Michael Catanzaro]

WebKitGTK+ and WPE WebKit Security AdvisoryWSA-2018-0006


Date reported   : August 07, 2018
Advisory ID : WSA-2018-0006
WebKitGTK+ Advisory URL : 
https://webkitgtk.org/security/WSA-2018-0006.html
WPE WebKit Advisory URL : 
https://wpewebkit.org/security/WSA-2018-0006.html

CVE identifiers : CVE-2018-4246, CVE-2018-4261, CVE-2018-4262,
 CVE-2018-4263, CVE-2018-4264, CVE-2018-4265,
 CVE-2018-4266, CVE-2018-4267, CVE-2018-4270,
 CVE-2018-4271, CVE-2018-4272, CVE-2018-4273,
 CVE-2018-4278, CVE-2018-4284, CVE-2018-12911.

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 

[webkit-gtk] WebKitGTK+ and WPE WebKit Security Advisory WSA-2018-0005

[Michael Catanzaro]

WebKitGTK+ and WPE WebKit Security AdvisoryWSA-2018-0005


Date reported   : June 13, 2018
Advisory ID : WSA-2018-0005
WebKitGTK+ Advisory URL : 
https://webkitgtk.org/security/WSA-2018-0005.html
WPE WebKit Advisory URL : 
https://wpewebkit.org/security/WSA-2018-0005.html

CVE identifiers : CVE-2018-4190, CVE-2018-4192, CVE-2018-4199,
 CVE-2018-4201, CVE-2018-4214, CVE-2018-4218,
 CVE-2018-4222, CVE-2018-4232, CVE-2018-4233,
 CVE-2018-11646, CVE-2018-11712,
 CVE-2018-11713, CVE-2018-12293,
 CVE-2018-12294.

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 

Re: [webkit-gtk] which compositor webkitgtk use? Did the webkitgtk needs "weston" or other 3rd party compositor implementation?

[Michael Catanzaro]

On Thu, Jun 7, 2018 at 2:44 AM, tugouxp <13824125...@163.com> wrote:
from the code above, it seems the webkitgtk  create its own display 
device and as a server, waiting for client connection.


Yes

so , did this mean the webkitgtk has its own compositor 
implementation instead?


Yes


and can be run without weston ?


And no! WebKit's compositor is a *nested* compositor run by the UI 
process. Each WebKitWebProcess is a Wayland client of the UI process. 
But the UI process is still itself a Wayland client of whatever 
compositor your desktop is using (Weston, mutter, etc.).


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

[webkit-gtk] Proposal: remove WebKitPluginProcess2 in WebKitGTK+ 2.28

[Michael Catanzaro]

Hi,

I propose we remove WebKitPluginProcess2 in WebKitGTK+ 2.28 (March 2020 
release). It's mainly useful for Flash, and that's going away from 
other browsers in 2020, so two years longer should be sufficient.


I think it would be nice to remove the main WebKitPluginProcess as well 
at that time, since Flash is the only NPAPI plugin that still works in 
other web browsers. However, the plugin process itself doesn't really 
ever slow down development, so I care less about that. In contrast, 
WebKitPluginProcess2 occasionally causes tricky problems (usually 
linker errors), and complicates the build by requiring we build a bunch 
of files twice (making it difficult to unify many source files). So I'd 
be plenty happy if we just got rid of WebKitPluginProcess2.


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] guchar * sometimes a utf8, sometimes utf16?

[Michael Catanzaro]

On Thu, May 31, 2018 at 5:05 PM, Leo Ufimtsev  
wrote:

Hello guys,

The following function:
guchar * webkit_web_resource_get_data_finish(..)

Sometimes returns utf8 and sometimes utf16. Is there a way to tell 
them apart?


Thank you.


Hm, good question. I don't know the answer, but here are some thoughts 
anyway:


We use guchar instead of gchar to indicate that it's a byte array, not 
a string, so it's not expected to be UTF-8. In fact, it could be any 
arbitrary encoding, not just UTF-16. I've seen more esoteric encodings 
before, particularly for CJKV websites. Of course, it might not be an 
HTML resource at all, it could be an image or an executable file or 
anything.


Assuming you know it is an HTML doc, then I think you want to parse the 
charset from the meta tag. Of course, that's a bit difficult because 
you do not know the encoding you should be using to parse it until 
after you have somehow successfully parsed it. I don't know how you 
would do it, but clearly WebKit knows how, somewhere. In Epiphany, our 
use is limited to saving resources on disk, which then get parsed by 
other applications when you open them, which is why we've never needed 
to deal with this problem.


For a website loaded via HTTP, the encoding could also have been set by 
an HTTP header. There's really nothing you can do in that case, as you 
don't have access to that.


I think Firefox uses an encoding detector. WebKit does not, but it's 
one option. ICU can do this, as can uchardet. Problem is, they are 
probabilistic and do not work well for some important encodings (e.g. 
GB18030). But that might work well enough for your needs.


Michael

___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk

Re: [webkit-gtk] mingw version of webkitgtk+2?

[Michael Catanzaro]

On Thu, May 10, 2018 at 11:41 AM, Dov Grobgeld  
wrote:
Sorry to hear that. Is there a list somewhere describing what doesn't 
compile/run for Windows? Is the problem just WebKitGtk or is it 
WebKit itself that hasn't been ported? Just curious what the main 
obstacle is.


The WebKit layer (formerly WebKit2) needs to be ported, yes. Sony is 
slowly working on this [1], so they would be the best people to ask 
about the status, and you could collaborate with them if interested.


Then GTK-specific code will also need to be ported. We've assumed that 
PLATFORM(GTK) implies !OS(WINDOWS) for a long time.


Finally, if you do get it working, know that it will break continually 
in future releases unless you actively keep fixing Windows-specific 
issues. (E.g. the macOS build has apparently not worked for about a 
year now.)


Michael

[1] 
https://trac.webkit.org/log/webkit/trunk/Source/WebKit/PlatformWin.cmake


___
webkit-gtk mailing list
webkit-gtk@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-gtk