See also bug #1872823 for the original qtwebkit package.

This is just not practical at this time. We're already happy if we can get rid of Qt4WebKit.

Instead of killing qt5-qtwebkit entirely, should we maybe try shipping a snapshot from annulen's qtwebkit-dev or qtwebkit-dev-wip branches?

You could talk to him about that, but I understand it's not ready for distros yet. If it was, he would release it.

I don't think it's a sustainable strategy anyway. Last commit to his development branch is in April. It's based on WebKit trunk from October last year. That's a lot better than 2016, but we've had a couple dozen CVEs since then that aren't yet fixed there. Even if we were to update now, before it's ready, we'll wind up back in the same place before long. QtWebKit has no future unless someone has $$$$$$/year to hire a small team of devs to help out. Surely it would be better to focus on porting apps to QtWebEngine and removing apps that cannot be ported.

BTW, popular applications will not port themselves without a flag date. The clear set date at which WebKitGTK was to be removed from Fedora was the only way we managed to get WebKitGTK apps ported.

One big problem with QtWebEngine is that it is based on Chromium whose upstream rejects almost any contribution, as a result there no official support for eg. ppc64le in QtWebEngine :-(

So I actually forgot about this, but there is also QtWPE, which is basically WebKitGTK with all the usual GNOME deps, except with the GTK dependency removed, a QtWebKit API layered on top, and friendly non-abandoned upstream. I haven't tried it and I assume desktop integration will be a lot worse, but in theory it should be API-compatible, and at least it should receive security updates shortly after WebKitGTK. Maybe that's the path forward? (We would probably be first to attempt replacing it at the distro level....)

(In reply to Michael Catanzaro from comment #4)
> You could talk to him about that, but I understand it's not ready for
> distros yet. If it was, he would release it.

Well, I would rather ship an experimental version of QtWebKit than none at all.

> BTW, popular applications will not port themselves without a flag date. The
> clear set date at which WebKitGTK was to be removed from Fedora was the only
> way we managed to get WebKitGTK apps ported.

That assumes that they care about being included in Fedora to begin with, which I think is much less of a motivation in the Qt/KDE world than in the GTK/GNOME world.

And even for your WebKitGTK flag day, several popular applications were unable to meet it and were either removed or shipped with a bundled WebKitGTK (which is really silly, because now instead of one copy of a vulnerable codebase, you have several of them).

(In reply to Michael Catanzaro from comment #6)
> So I actually forgot about this, but there is also QtWPE, which is basically
> WebKitGTK with all the usual GNOME deps, except with the GTK dependency
> removed, a QtWebKit API layered on top, and friendly non-abandoned upstream.

From your link:
> WPEQt provides a QML plugin implementing […]
but pretty much all the QtWebKit users are QWidgets applications, not QML applications. So this is not going to be a viable alternative for them.

(In reply to Kevin Kofler from comment #7)
> And even for your WebKitGTK flag day, several popular applications were
> unable to meet it and were either removed or shipped with a bundled
> WebKitGTK (which is really silly, because now instead of one copy of a
> vulnerable codebase, you have several of them).

Which applications do still ship a bundled outdated webkitgtk? I only know of GnuCash which did this for a while but GnuCash only used it to display self-generated charts (i.e. trustworthy/safe content). And I think it does not do so any more. Also, I doubt any other package does as the following command lists no package:
$ dnf repoquery --whatprovides webkitgtk

A linux distribution like Fedora is also about responsibility for our users. Having this extremely unsecure code interact with untrustworthy content like websites is a huge risk for our users basically handing out their computers and data to any criminal hacker. When recommending people to use Fedora I don't want to care about telling them which packages not to install. In case you object this responsibility, why don't we make all the other security features (like PIE, privilege separation, passwords, …) optional?

It's pretty obvious at this point that volunteers to port packages are not going to emerge. Unless you set a flag date, like we did for WebKitGTK, you're going to be stuck with QtWebKit indefinitely.

(In reply to Christian Stadelmann from comment #8)
> Which applications do still ship a bundled outdated webkitgtk?

I'm not aware of any doing so.

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

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
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 '34'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 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.

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 exists, problem still there on F39.