Michael Catanzaro wrote:
> As a browser maintainer itself, I'm very supportive of the Falkon
> project. I consider it to be KDE's equivalent of Epiphany, sort of a
> sister project, more or less.
Agreed. I also think that the "Workstation Edition" should be shipping
Epiphany instead of Firefox (also the main thing that keeps it from being a
true "GNOME Spin", though the naming is of course also marketing), but
myself not using GNOME, I admittedly do not care as much about that than
about Falkon which I maintain in Fedora and would really like to finally see
as the default (and ideally only) browser on the KDE Spin.
> I looked into this a couple months ago and if I remember correctly,
> they *are* impressively backporting quite a few CVE fixes, but I don't
> think they are *comprehensively* doing so? My suspicion is that if a
> fix does not apply cleanly, or looks difficult, they probably move on
> to the next one? It's really hard just to determine whether a fix is
> still required. (Disclaimer: I'm not looking at the git repo right now
> or cross-referencing to a list of Chromium CVEs. May be wrong. Don't
> treat this as gospel.)
Well, one issue is that, as far as I can tell, Google does not always
document which commit fixes a given CVE. For most CVEs, they do, but for
some (maybe those discovered by Apple which is famously against any sort of
responsible disclosure and in favor of strict "security by obscurity"?),
there is an awful lack of details. So, obviously, it is hard to identify the
fixes to backport in those cases.
But one thing to also keep in mind is that not all Chrome/Chromium CVEs also
affect QtWebEngine. Some are in code that is only shipped in the Chrome
and/or Chromium browser and not in derived browsers/libraries like
QtWebEngine. So just comparing the lists of fixed CVEs also does not tell us
the whole truth. It is not obvious how many CVEs should be fixed in
QtWebEngine, but are not.
> Additionally, I don't know about Chromium, but in WebKit I recently
> estimated that only about 5% of issues flagged as fixing security
> vulnerabilities receive CVEs. (Maybe Chromium does better at this?) And
> it is impossible to know what percentage of security fixes get flagged
> as such, but my guess is that percentage is itself pretty low. I'd
> further guess that the situation with Chromium is similar. So even if
> you backport fixes for every single CVE, you will not be in good shape.
QtWebEngine also backports some security fixes with only a Chromium bug ID
("security bug nnnnnnnnn"), but that is rather the exception. I obviously do
not know how many security fixes remain undiscovered by the backporters.
> My conclusion was that QtWebEngine was that the Qt 5 version is too
> old. I think QtWebEngine should adopt the same strategy that WebKitGTK
> and Firefox ESR use: regularly rebase to latest upstream version.
> WebKitGTK does that twice per year. Firefox does it every 9 months.
> Backports are an appropriate way to fill the gap between rebases, but
> they are NOT a substitute for regular rebases.
Well, Qt does pretty much exactly that, *but* the problem is, Qt 5 is in LTS
"very strict" mode by now, i.e., in maintenance mode. From the point of view
of Qt, applications are not supposed to use it anymore. The Qt 6 QtWebEngine
has been rebased several times since. The problem is that the KDE ecosystem
cannot move on to Qt 6 as fast as Qt upstream would like it to. In part due
to Qt itself (e.g., QtWebEngine was not included at all in 6.0 and 6.1!), in
part due to the KDE Frameworks (which are being ported to Qt 6 right now,
they were blocked due to the aforementioned missing features in Qt 6
itself). So we are stuck on the legacy branch.
Maybe an unofficial backport of QtWebEngine 6.2 LTS, QtWebEngine 6.4, and/or
the upcoming QtWebEngine 6.5 LTS to Qt 5 would help close the gap. But
someone would have to do the work (and hope not to get sued by Qt over
trademarks).
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
