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.
On Tue, Feb 14 2023 at 03:44:06 AM +0100, Kevin Kofler via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Even Qt 5 QtWebEngine (considered obsolete by Qt) still gets security
fixes,
and they are published in git under the LGPL as soon as the
commercial Qt
5.15.x LTS release is released. (In fact, they are pushed even
earlier, as
soon as they are backported by Qt developers, and the branch is then
tagged
when the commercial LTS is released. But the backports typically
happen on
the Qt release schedule, meaning they are usually only done in git
when a Qt
release is planned soon, not daily.)
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.)
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.
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.
Michael
_______________________________________________
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
