Policy regarding QtWebKit and QtScript

[Kevin Kofler]

I've been digging deep into QtWebEngine in the hope of to polishing it up 
for Fedora (which sounds less hopeless now that Fedora has become less 
strict on bundled libraries), seeing how QtWebKit has no future with nobody 
fixing security bugs in it, so let me clear up a few misconceptions in your 
post:

Vadim Zhukov wrote:
> Same applies to OpenBSD. QtWebEngine uses its own, qmake-based, build
> system, so at least 50% of effort of porting Chromium should be
> repeated.

The Chromium part is actually built using gyp. QMake just shells out to gyp 
to build it. You can add gyp flags in the src/core/config/*.pri files 
(you'll probably want a config/openbsd.pri anyway, unless you abuse 
linux.pri).

> Next thing is that chromium already requires some tricks to allow it
> being compiled (or, more technically, linked) on 32-bit platforms. In
> fact, on OpenBSD it currently packages on i386 and amd64; it's going
> to became amd64 soon:
> http://betanews.com/2015/11/30/google-killing-chrome-for-32-bit-linux/
> . QtWebkit is large enough, too, but still fits into 32-bit address
> space. That's not about trashing swap partition; that's about being
> able to link stuff at all.

That article is about the proprietary Chrome. It even explicitly says that 
Chromium will keep supporting 32-bit x86.

What it does require though (on x86) is SSE2. In case anybody is interested, 
I have a patch fixing that (basically a cumulative revert of all the related 
upstream changes) that I still need to test. Here is what I have so far:
https://bugzilla.redhat.com/attachment.cgi?id=1108340&action=diff
but it might not even compile yet.

> KDE4 runs on OpenBSD/sparc64 (I had successful reports from users).
> Chromium doesn't work there due to (at least) memory alignment bugs.
> QtWebEngine is out of SPARC game, therefore, too. Adoption of
> QtWebEngine will mean no modern KDE for sparc64. And it's a 64-bit
> platform, not limited by 2/3/4GB of address space! I'm not ever
> talking about MIPS world...

You'd also need a V8 port, which means a JIT for that platform (because V8 
has no interpreter fallback). This is a major concern with QtWebEngine, it 
destroys the portability of Qt and KDE to new architectures. We were happy 
when the V8 dependency was dropped from QML 2, and very unhappy when it was 
reintroduced through the backdoor with QtWebEngine.

> And, as it was already mentioned many times, Chromium/QtWebEngine
> bundles a lot of software, often outdated. What happens when a
> security flaw is found in, say, giflib? - The packager adds an
> upstream patch or rolls a new release from upstream. What happens in
> case of bundled copy? - Nothing, because chromium developers don't
> want to break things and thus do not care about updating software
> ASAP. And if they do, those updates are delayed because the
> chromium/Qt packages need to be redone (reviewed, rebuilt, repackaged
> and verified). And that's far less trivial and takes far more time
> than patching and repackaging giflib. End users get unsecure software
> as a result, possible even thinking: "I'm secure now, since I've just
> updated giflib package". Who'll stand up and say: "I want to make
> users of my software feel safe while my software is actually unsafe"?
> - Noone will, right? But it happens.

This is a very valid concern. Qt upstream has done some work on unbundling 
libraries, but:
1. There are libraries where Chromium does not support unbundling.
2. There are a few libraries that Chromium allows to unbundle, but
   QtWebEngine doesn't yet.
3. The unbundling in QtWebEngine does not run replace_gyp_files.py, so the
   unbundling is not complete.
2. and 3. are easy to fix, this patch works for me:
http://copr-dist-git.fedorainfracloud.org/cgit/kkofler/qtwebengine/qt5-qtwebengine.git/tree/qtwebengine-opensource-src-5.6.0-beta-linux-pri.patch?id=849178c1d044af50e13552490c81801565aef547

I'm looking into upstreaming it to Qt, but I'll have to add configure checks 
for the use_system_* flags (point 2.) that I hardcoded to "=1".

But issue 1. is the bigger issue.

That said, your example is actually a bad example because 
Chromium/QtWebEngine does not actually bundle giflib. (It uses its own GIF 
decoder, which is forked from WebKit's, which is forked from Mozilla's.)

        Kevin Kofler