Re: Fedora Linux 38 blocker status summary

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux