Policy regarding QtWebKit and QtScript

[Thomas Friedrichsmeier]

Hi,

On Sat, 05 Mar 2016 09:58:34 +0100
Niels Ole Salscheider <niels_ole at salscheider-online.de> wrote:
> On Saturday, 5 March 2016, 08:09:22 CET, Thomas Friedrichsmeier wrote:
> > This is not only an uncomfortable situation for a free software
> > project to be in. If you're trying to interface with third
> > libraries that happen to be MinGW-only, for various reasons, it can
> > be between no-fun-at-all, and downright incompatibility. Remember,
> > the C++-ABI is just not compatible between MinGW and MSVC.
> 
> I agree that this is a bad situation. Are there any plans from
> upstream to fix this at some point?

Looks somewhat grim, although, hopefully this is not the last word:
https://bugreports.qt.io/browse/QTBUG-42725
 
> The problem with QtWebKit really is that it probably has many
> vulnerabilities that are fixed in upstream WebKit but where the fixes
> are not backported. It would probably be ok to use it for "trusted
> local HTML" but I am not sure how many cases there are where you can
> guarantee this. And using QtWebKit half of the time and QtWebEngine
> for the other half does not necessarily solve your Windows problem.

True, but it would make it somewhat less severe. The more frameworks /
applications play nice with _both_ compilers, the more likely that I
can combine all required bits for my purpose on at least _one_ compiler.
 
> Btw, do we already have an official policy regarding QtWebEngine?
> There are already KDE applications using it, but is it ok to
> hard-depend on it or should it be optional for now?

Dunno. Of course, as things stand, in the mid term, applications in need
of a _secure_ html viewer will have basically no other choice than
to hard-depend on QtWebEngine. But I would argue for a policy along
the lines of:

  - Do not hard depend on QtWebEngine, unless you really have to.
    - Where security is _not_ a concern, you should (optionally) support
      compilation with QtWebKit.
    - Where security _is_ a concern, consider whether you can
      (optionally) use an external browser for the purpose at hand.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20160305/93999897/attachment.sig>