Bug 1711519

This problem is known, but removing this compatibility package is not possible at this time due to dependencies. Upgrading to current WebKit is also not easily possible because they removed Qt 4 support. (The sorta-maintained QtWebKit community fork is also Qt 5 only.)

Wouldn't it be better to file bugs against all the dependencies and stating a deadline (that's what they did with Gtk's old WebKit bindings)? Having this dependency lying around is a bomb waiting to explode some time.

I suppose we first need to determine the true set of affected packages. Currently, kdelibs 4 is built against QtWebKit 4, so "dnf remove qtwebkit" wants to remove everything kdelibs4. But I know at least the following are definitely affected:
* amarok: IIRC, there's some experimental KF5 port somewhere that we could try to package. No idea how well that works.
* knode: This one is most problematic. There is no KF5 port and no real alternative. (I don't know of any other Qt NNTP client.) I proposed attempting to downgrade to some ancient version that still used KHTML rather than QtWebKit and that also did not require the obsolete KDE 4 Akonadi libraries. KDE SIG people did not like that idea. But it might be the only way out, so I might try getting that done somehow.
* qt4-assistant: This one could be built without QtWebKit using QTextEdit to view HTML instead, but the problem is that this will lead to a much worse rendering of the documentation. Still, for the legacy Qt 4 stuff, it might be good enough.

But there might be more affected packages.

This is the full list of dependencies according to DNF (minus i686 architecture versions and minus multiple versions of the same package):

$ dnf repoquery --whatrequires qtwebkit --alldeps | grep --invert-match "i686"
OpenSceneGraph-examples-qt-0:3.4.1-9.fc30.x86_64
PyQt4-webkit-0:4.12.3-6.fc30.x86_64
amarok-0:2.9.0-4.fc30.x86_64
arc-gui-clients-0:0.4.6-18.fc30.x86_64
arora-0:0.11.0-20.fc30.x86_64
brewtarget-0:2.1.0-3.fc23.x86_64
freecad-1:0.18-2.fc30.x86_64
gambas3-gb-qt4-webkit-0:3.11.4-6.fc30.x86_64
kde-runtime-libs-0:17.08.3-11.fc30.x86_64
kdelibs-6:4.14.38-10.fc30.x86_64
kdelibs-webkit-6:4.14.38-10.fc30.x86_64
knode-libs-0:4.14.10-40.fc30.x86_64
krecipes-0:2.1.0-9.fc30.x86_64
ksysguard-libs-1:4.11.22-25.fc30.x86_64
libkfbapi-0:1.0-14.fc30.x86_64
marble-widget-1:15.08.3-60.fc30.x86_64
python2-pyside-0:1.2.4-8.fc30.x86_64
python3-PyQt4-webkit-0:4.12.3-6.fc30.x86_64
python3-pyside-0:1.2.4-8.fc30.x86_64
qlandkartegt-0:1.8.1-19.fc30.x86_64
qmc2-0:0.195-6.fc30.x86_64
qt-assistant-1:4.8.7-49.fc30.x86_64
qt-demos-1:4.8.7-49.fc30.x86_64
qt-designer-plugin-webkit-1:4.8.7-49.fc30.x86_64
qt-examples-1:4.8.7-49.fc30.x86_64
qt4pas-0:2.5-18.fc30.x86_64
qtscriptbindings-0:0.2.0-19.fc30.x86_64
qtwebkit-devel-0:2.3.4-25.fc30.x86_64
quiterss-0:0.18.12-2.fc30.x86_64
qutim-0:0.3.2-5.git.6f3a98a.fc23.x86_64
rekonq-0:2.4.2-14.fc30.x86_64
smokeqt-0:4.14.3-15.fc30.x86_64
timetablemate-0:0.10-0.22.20111204git.fc30.x86_64
tomahawk-libs-0:0.8.4-22.fc30.x86_64

I think you really should either try to fix these hundreds of known CVEs (I wouldn't do that as upstream has abandoned qt4 webkit bindings) or retire this package as soon as possible, i.e. for F31.

A suitable version of KNode that would also eliminate the need for KDE 4 Akonadi libraries (which is silly because the KDE 4 Akonadi server is not actually getting run anymore) would be 4.3.x., 4.4.x or the enterprise/e4 branch.

(In reply to Christian Stadelmann from comment #4)
> This is the full list of dependencies according to DNF (minus i686
> architecture versions and minus multiple versions of the same package):

This is a whole bunch of packages, which actually strengthens my CANTFIX assertion. It is just not practical to remove all these packages. Your list includes high-profile applications such as Amarok and FreeCAD that are still stuck on Qt 4 for some reason, and applications such as KNode that are no longer active upstream but have no viable replacement.

Your list also includes several language bindings (gambas3-gb-qt4-webkit, several Python bindings, qt4pas, qtscriptbindings, smokeqt), so there may be more affected packages through indirect dependencies.

In fairness Kevin, at least some (arguably many) of the affected packages in the dependency list can be built without qtwebkit (either because it's an optional feature or can be patched-out without a lot of trouble).

Removing this doesn't have to happen at next release, but it does and should happen eventually.  Tracking progress of doing so here makes sense to me.

I'll re-open and mark as FutureFeature for now.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

*** Bug 1872823 has been marked as a duplicate of this bug. ***

Updated list from the duplicate:

$ repoquery --whatrequires qtwebkit
Last metadata expiration check: 0:09:22 ago on Wed 26 Aug 2020 11:43:11 AM CDT.
OpenSceneGraph-examples-qt-0:3.4.1-16.fc32.x86_64
amarok-0:2.9.0-6.fc32.x86_64
arora-0:0.11.0-22.fc32.x86_64
brewtarget-0:2.1.0-14.fc32.x86_64
gambas3-gb-qt4-webkit-0:3.14.3-2.fc32.x86_64
kde-runtime-libs-0:17.08.3-14.fc32.i686
kde-runtime-libs-0:17.08.3-14.fc32.x86_64
kdelibs-6:4.14.38-20.fc32.i686
kdelibs-6:4.14.38-20.fc32.x86_64
kdelibs-webkit-6:4.14.38-20.fc32.i686
kdelibs-webkit-6:4.14.38-20.fc32.x86_64
knode-libs-0:4.14.10-43.fc32.i686
knode-libs-0:4.14.10-43.fc32.x86_64
krecipes-0:2.1.0-11.fc32.x86_64
ksysguard-libs-1:4.11.22-27.fc32.i686
ksysguard-libs-1:4.11.22-27.fc32.x86_64
libkfbapi-0:1.0-16.fc32.i686
libkfbapi-0:1.0-16.fc32.x86_64
marble-widget-1:15.08.3-62.fc32.i686
marble-widget-1:15.08.3-62.fc32.x86_64
python3-PyQt4-webkit-0:4.12.3-11.fc32.x86_64
qlandkartegt-0:1.8.1-23.fc32.x86_64
qlandkartegt-0:1.8.1-24.fc32.x86_64
qmc2-0:0.195-11.fc32.x86_64
qt-assistant-1:4.8.7-52.fc32.x86_64
qt-assistant-1:4.8.7-55.fc32.x86_64
qt-demos-1:4.8.7-52.fc32.x86_64
qt-demos-1:4.8.7-55.fc32.x86_64
qt-designer-plugin-webkit-1:4.8.7-52.fc32.i686
qt-designer-plugin-webkit-1:4.8.7-52.fc32.x86_64
qt-designer-plugin-webkit-1:4.8.7-55.fc32.i686
qt-designer-plugin-webkit-1:4.8.7-55.fc32.x86_64
qt-examples-1:4.8.7-52.fc32.i686
qt-examples-1:4.8.7-52.fc32.x86_64
qt-examples-1:4.8.7-55.fc32.i686
qt-examples-1:4.8.7-55.fc32.x86_64
qt4pas-0:2.5-20.fc32.i686
qt4pas-0:2.5-20.fc32.x86_64
qtscriptbindings-0:0.2.0-21.fc32.i686
qtscriptbindings-0:0.2.0-21.fc32.x86_64
qtwebkit-devel-0:2.3.4-29.fc32.i686
qtwebkit-devel-0:2.3.4-29.fc32.x86_64
rekonq-0:2.4.2-16.fc32.x86_64
timetablemate-0:0.10-0.24.20111204git.fc32.x86_64
tomahawk-libs-0:0.8.4-23.fc31.i686
tomahawk-libs-0:0.8.4-23.fc31.x86_64

At least FreeCAD seems to be gone from this list now.

While I think we need to do something about Qt4WebKit, also because it depends on Python 2 to build, which is not going to be allowed forever, we first need a plan for each of the affected packages. Options include:
* replacing the package with a Qt 5 port or replacement application,
* building the package without QtWebKit support, e.g., using QTextBrowser (which is much crappier, but may be sufficient for some uses) instead,
* as a last resort, retiring the package without replacement.

From this list:
* arora and rekonq should just be retired. Especially a web browser using an insecure web component makes no sense whatsoever to ship. In addition, we have a replacement: Falkon (which uses QtWebEngine). As the maintainer of Falkon, I can add Obsoletes: arora rekonq to falkon.spec if desired as part of retiring the obsolete browsers.
* For amarok, I think we should ship amarok git master from https://invent.kde.org/multimedia/amarok instead of the ancient kdelibs4 version.
* For KNode: have we tried yet to build kdepim4 with KDEPIM_NO_WEBKIT? That should make the message viewer use QTextBrowser instead. HTML is not all that common on newsgroups or (Gmane-gatewayed) mailing lists, so it may be good enough. (The alternative would be to downgrade all the way to 4.4 to use KHTML, which is a bigger can of worms.)
* Likewise, the Qt 4 Assistant can, as far as I know, be built with QTextBrowser.
* Several of the packages in the list are bindings or wrappers (e.g., kdewebkit in kdelibs) of some kind. For those, we need to check the transitive dependencies before retiring them. Especially the users of bindings for non-C++ languages are probably not directly linked to QtWebKit itself.

Once the dependent packages are either built without QtWebKit or retired, only at that point can QtWebKit be retired. (The same, by the way, goes for Qt5 QtWebKit. Though I do not see that one realistically go away any time soon.)

krecipes uses QtWebKit only for printing, so I would need to either revert https://github.com/KDE/krecipes/commit/cd1490fb5fe82cbe9172a43be13298001b446ecd or find some other way to print the temporary HTML file (append a line of JavaScript to open the print dialog in the browser and then open the HTML file with KRun or xdg-open?).

for the record, qlandkarteqt can be retired when needed, it still works, but is a dead project that has been replaced by qmapshack

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

I'd like to work on this and have drafted the following change proposal:

https://fedoraproject.org/wiki/User:Smani/QtwebkitRemoval

Feedback welcome.

Feedback here: https://www.spinics.net/lists/fedora-devel/msg280214.html

And the urgent qt-mobility issue should be fixable: https://www.spinics.net/lists/fedora-devel/msg280215.html so I am strongly opposed to your sledgehammer approach. We *first* need to get the reverse dependencies of Qt4WebKit fixed or dropped, *then* we can drop the package, not the other way round.

(In reply to Kevin Kofler from comment #16)
> Feedback here: https://www.spinics.net/lists/fedora-devel/msg280214.html

Link to the thread on Fedora infra:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MGACZZ2PNDIRPVPG7E2VUBJ6LJKMT7NV/

> […] I am strongly
> opposed to your sledgehammer approach. We *first* need to get the reverse
> dependencies of Qt4WebKit fixed or dropped, *then* we can drop the package,
> not the other way round.

There has been time for that in the last 6 years to do so. Announcing the removal of Qt4's WebKit now is perfect as it gives enough time for the qt-mobility maintainer(s) to fix their package. You can help them by creating a pull request to their package: https://src.fedoraproject.org/rpms/qt-mobility 

If they don't manage to do so, the package is unmaintained and should be removed from Fedora anyway.

(In reply to Christian Stadelmann from comment #17)
> There has been time for that in the last 6 years to do so. Announcing the
> removal of Qt4's WebKit now is perfect as it gives enough time for the
> qt-mobility maintainer(s) to fix their package. You can help them by
> creating a pull request to their package:
> https://src.fedoraproject.org/rpms/qt-mobility 

Actually, as a provenpackager, I can fix it directly and I did:
https://src.fedoraproject.org/rpms/qt-mobility/c/b1f31d037943bbc56bd236f48f78ff061f2552a5?branch=master
https://koji.fedoraproject.org/koji/buildinfo?buildID=1639011

(In reply to Kevin Kofler from comment #18)
> Actually, as a provenpackager, I can fix it directly and I did:
> https://src.fedoraproject.org/rpms/qt-mobility/c/
> b1f31d037943bbc56bd236f48f78ff061f2552a5?branch=master
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1639011

Oh, thanks!

Kevin, thanks for your feedback in the change page. How do you prefer to move ahead? Shall I submit the change proposal? Do you want to indicate which packages you'd prefer to work on yourself and which ones I should deal with myself?

Do you still want to implement this for F34? It is late for a system-wide change now, you would have to apply for a late change exception. I can take care of at least kdepim4/knode and krecipes.

Who will take care of kdelibs, kde-runtime(-libs), and kde-workspace? (RHEL patches can be helpful there.) Do I have to do it or do we have another volunteer?

The qt package itself also needs some love, switching assistant to QTextBrowser and removing QtWebKit-based demos and examples.

(The rest simply needs to be upgraded or retired.)

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Changing back to rawhide. It is now too late to do this for F34. Let me know if there is interesting in pulling this off for F35, then I will try to start building Qt 4 packages without QtWebKit or upgrading them to Qt 5 or 6 development snapshots where that is an option (e.g., Amarok). Only packages where neither is possible will be retired, in particular, Arora and Rekonq (where I can add Obsoletes: to the Falkon package so that people do not end up without a browser).

That sounds like a good plan to me.

What I would like is buy in to the plan from the affected package maintainers, both so that I do not stomp on other people's packages and because I would really appreciate not having to do all the work alone.

The current per-package plan is:
https://fedoraproject.org/wiki/User:Smani/QtwebkitRemoval#Detailed_Description

This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

(In reply to Kevin Kofler from comment #11)
> […]
> From this list:
> * arora and rekonq should just be retired. Especially a web browser using an
> insecure web component makes no sense whatsoever to ship. In addition, we
> have a replacement: Falkon (which uses QtWebEngine). As the maintainer of
> Falkon, I can add Obsoletes: arora rekonq to falkon.spec if desired as part
> of retiring the obsolete browsers.

I think this is a good Idea. Can you please do so?

> * For amarok, I think we should ship amarok git master from
> https://invent.kde.org/multimedia/amarok instead of the ancient kdelibs4
> version.

+1

> […]
> Once the dependent packages are either built without QtWebKit or retired,
> only at that point can QtWebKit be retired. (The same, by the way, goes for
> Qt5 QtWebKit. Though I do not see that one realistically go away any time
> soon.)

I object. With Gtk's deprecated version of the WebKit bindings, it was done the other way around: It was announced that the package will be dropped soon and everyone would have to fix their packages or they will fail to build and get retired. As this issue is very security sensitive and parsing any website with QtWebKit is basically allowing remote code execution for everyone I think this is the way to go.

And I objected to the way this was done for Gtk and still disagree that this is a reasonable way to handle compatibility libraries. For the security issue, please keep in mind that most of the affected applications (except arora and rekonq, of course!) do not actually try to parse every website on Earth with QtWebKit. Some, like KRecipes, only use QtWebKit on local content. Some, like Amarok, typically only view specific sites such as Wikipedia. And some, like KNode, (by default) only view HTML to begin with after user confirmation, exactly because of security concerns. (KNode does not actually view websites either, but NNTP posts are of course no less likely to attempt exploits. The required confirmation click is the mitigating factor.)

Just an update. Our QtWebKit package is currently based on WebKitGTK 2.12. I've done a quick manual count using https://webkitgtk.org/security and found 456 unfixed CVEs as of November 5, 2021. All but a few of those are remote code execution vulnerabilities. A handful of them are going to be specific to WPE/GTK, and many of them are probably bugs present in features that don't even exist in the old QtWebKit, but on the whole the situation isn't great.

If you don't set a deadline, you'll never successfully remove it, as evidenced by the age of this issue. We still have GTK 1 and GLib 1 in Fedora because the package maintainer will not let it die. So if you really want to see QtWebKit removed, you'll probably need to create a FESCo ticket, because otherwise Kevin or any other package can just unretire it if the current maintainer (Rex) lets it go.

One more note. QtWebKit has no sandbox available at all, so successful exploit is really full game over unless you are smart enough to run it under Flatpak with no sandbox holes.

(In reply to Michael Catanzaro from comment #31)
> Just an update. Our QtWebKit package is currently based on WebKitGTK 2.12.
> I've done a quick manual count using https://webkitgtk.org/security and
> found 456 unfixed CVEs as of November 5, 2021. All but a few of those are
> remote code execution vulnerabilities. A handful of them are going to be
> specific to WPE/GTK, and many of them are probably bugs present in features
> that don't even exist in the old QtWebKit, but on the whole the situation
> isn't great.
> 
> If you don't set a deadline, you'll never successfully remove it, as
> evidenced by the age of this issue. We still have GTK 1 and GLib 1 in Fedora
> because the package maintainer will not let it die. So if you really want to
> see QtWebKit removed, you'll probably need to create a FESCo ticket, because
> otherwise Kevin or any other package can just unretire it if the current
> maintainer (Rex) lets it go.

If I open the FESCo ticket, will I have to do the work? Or who will work on it?

Background: I'm not investing much time into Fedora currently and I doubt that I will be able to get the work done.

Opening a FESCo ticket will not require that you do implementation work, but it also won't force anybody else to do the work either. FESCo decisions unblock volunteers, but do not force work.

It would probably be productive to take this step regardless. Anything still using QtWebKit should have been removed from the distribution 8-9 years ago.

I still object to removing libraries as long as they are still used by applications. There is a plan that looks workable to get rid of Qt4WebKit, but that is only Qt4WebKit (the qtwebkit) package and does NOT cover Qt5WebKit (qt5-qtwebkit), because in fact, the migration path for some of the packages is to qt5-qtwebkit. Getting all applications ported to QtWebEngine is not feasible downstream.

(see https://fedoraproject.org/wiki/User:Smani/QtwebkitRemoval#Detailed_Description – removing the Qt 4 qtwebkit (which is even older than the Qt 5 one) may be doable by that plan, if everything works out as explained there, but removing all QtWebKit is not and there is no plan for it)

> because in fact, the migration path for some of the packages is to qt5-qtwebkit

"because" was maybe the wrong word there, because there are actually way more packages already using qt5-qtwebkit than the few ones that would move from the Qt 4 WebKit to the Qt 5 one under the plan. We have no migration path for those either. (That package that someone linked to that wraps webkitgtk with QML is not a workable upgrade path either because it is QML only whereas the affected applications are all using the C++/QtWidgets API.)

I mean, we can just keep saying the same things again and again? I think everything using QtWebKit should have been retired a decade ago when QtWebKit was deleted from WebKit upstream. I assume you think it should be allowed to remain in Fedora forever (which it certainly will, if there is no cut-off date). Obviously nobody is ever going to fix things without a hard cut-off, given that it hasn't happened yet after nearly a decade.

WebKitGTK 2.12 -- which our current QtWebKit package is still based on -- was released in March 2016. Time flies....

I've changed this bug report back to rawhide and hope that we can get this package dropped in time for Fedora 37.

@sudar2 : I've updated your proposal and removed a few packages that are unrelated: https://fedoraproject.org/wiki/User:Smani/QtwebkitRemoval
Would you still want to publish the change proposal as is?

Everyone: Anything to add/change in the proposal above?

(In reply to Kevin Kofler from comment #24)
> Changing back to rawhide. It is now too late to do this for F34. Let me know
> if there is interesting in pulling this off for F35, then I will try to
> start building Qt 4 packages without QtWebKit or upgrading them to Qt 5 or 6
> development snapshots where that is an option (e.g., Amarok). Only packages
> where neither is possible will be retired, in particular, Arora and Rekonq
> (where I can add Obsoletes: to the Falkon package so that people do not end
> up without a browser).

This is the updated list (minus duplicates):

$ dnf repoquery --whatrequires qtwebkit | grep --invert-match "i686"
OpenSceneGraph-examples-qt-0:3.4.1-32.fc35.x86_64
amarok-0:2.9.0-12.fc35.x86_64
arora-0:0.11.0-25.fc35.x86_64
brewtarget-0:2.1.0-18.fc35.x86_64
gambas3-gb-qt4-webkit-0:3.16.2-3.fc35.x86_64
gambas3-gb-qt4-webview-0:3.16.2-3.fc35.x86_64
kde-runtime-libs-0:17.08.3-24.fc35.x86_64
kdelibs-6:4.14.38-28.fc35.x86_64
kdelibs-webkit-6:4.14.38-28.fc35.x86_64
knode-libs-0:4.14.10-47.fc35.x86_64
krecipes-0:2.1.0-14.fc35.x86_64
python3-PyQt4-webkit-0:4.12.3-17.fc35.x86_64
qmc2-0:0.195-19.fc35.x86_64
qt-assistant-1:4.8.7-65.fc35.x86_64
qt-demos-1:4.8.7-65.fc35.x86_64
qt-designer-plugin-webkit-1:4.8.7-65.fc35.x86_64
qt-examples-1:4.8.7-65.fc35.x86_64
qt4pas-0:2.5-23.fc35.x86_64
qtscriptbindings-0:0.2.0-25.fc35.x86_64
qtwebkit-devel-0:2.3.4-35.fc35.x86_64
rekonq-0:2.4.2-19.fc35.x86_64


(In reply to Kevin Kofler from comment #24)
> Changing back to rawhide. It is now too late to do this for F34. Let me know
> if there is interesting in pulling this off for F35, then I will try to
> start building Qt 4 packages without QtWebKit or upgrading them to Qt 5 or 6
> development snapshots where that is an option (e.g., Amarok). Only packages
> where neither is possible will be retired, in particular, Arora and Rekonq
> (where I can add Obsoletes: to the Falkon package so that people do not end
> up without a browser).

It would be nice if you could make Falkon obsolete arora and rekonq. And also if you could update amarok to some development snapshot.

@fedora Thanks for your work, I'm happy to publish the proposal, if there is anyone willing to become change co-owner and help with the tasks listed in the proposal, I'd appreciate it.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Package still present and not updated in F39.