Re: Comaintainer(s) wanted for qt5-qtwebengine
On 7/20/22 15:56, Michael Catanzaro wrote: > On Wed, Jul 20 2022 at 04:29:40 PM +0200, Kevin Kofler via devel > wrote: >> That is not a reasonable solution. Those applications need embedded >> HTML in >> the UI, not a separate browser window. And it does not help at all if >> the >> browser that is shelled out to itself uses QtWebEngine. > > I presume it uses a sandboxed multiprocess architecture anyway, like > upstream Chromium. Is it not true? > > If so, it's surely one of the most secure packages we have in Fedora. > Of course, that's no good excuse to fall behind on security updates. > But I have high confidence in Chromium's sandbox. There have been vulnerabilities, both in Chromium and (I believe) in the kernel, which can be used for sandbox escapes. Those vulnerabilities need to be patched very quickly. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
Michael Catanzaro wrote: > I presume it uses a sandboxed multiprocess architecture anyway, like > upstream Chromium. Is it not true? > > If so, it's surely one of the most secure packages we have in Fedora. > Of course, that's no good excuse to fall behind on security updates. > But I have high confidence in Chromium's sandbox. It is true. QtWebEngine uses the Chromium seccomp sandbox. (I can definitely confirm that because bugs in the sandbox policy, such as incompatibilities with newer glibc versions, immediately manifest in some or all web pages completely failing to render. I have had to fix a couple of these. So seccomp is definitely used.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
On Wed, Jul 20 2022 at 09:00:28 PM +0200, Kevin Kofler via devel wrote: (The fact that these fixes are not included in the betas, but only dropped into the stable release, also makes the beta testing quite pointless and compromises the stability of the stable releases.) A little feedback on why this happens. Every time you commit to a web browser engine, nation states scrutinize the commit looking for vulnerabilities that can be abused to hack users: both new vulnerabilities introduced in the commit, and also any vulnerabilities fixed in the commit. So it's unfortunately become important to minimize the amount of time between when the fix hits open source vs. when it reaches users. We've been struggling with this problem over in WebKit because we've historically been too transparent with security-relevant commits. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
On Wed, Jul 20 2022 at 04:29:40 PM +0200, Kevin Kofler via devel wrote: That is not a reasonable solution. Those applications need embedded HTML in the UI, not a separate browser window. And it does not help at all if the browser that is shelled out to itself uses QtWebEngine. I presume it uses a sandboxed multiprocess architecture anyway, like upstream Chromium. Is it not true? If so, it's surely one of the most secure packages we have in Fedora. Of course, that's no good excuse to fall behind on security updates. But I have high confidence in Chromium's sandbox. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
Vitaly Zaitsev via devel wrote: > On 20/07/2022 16:50, Kevin Kofler via devel wrote: >> There is a lag, but it is less than the average lag we add in Fedora. >> >> E.g., the security fixes from Chromium 100 were backported to >> qtwebengine- chromium git after 1 month, and the release was tagged 2 >> weeks later. > > This is not about the Fedora package, but about the QtWebEngine > upstream. They are months behind Chromium sources. But that is exactly what I am talking about! Chrome 100 was released 2022-03-29: https://chromereleases.googleblog.com/2022/03/stable-channel-update-for-desktop_29.html An additional security update for it was released 2 weeks later, 2022-04-11: https://chromereleases.googleblog.com/2022/04/stable-channel-update-for-desktop_11.html These fixes (those that are relevant to QtWebEngine to begin with – several of the bugs affect only Chromium UI code that is *not* part of QtWebEngine) have been backported to upstream qtwebengine-chromium.git (87-based branch, the one used in QtWebEngine 5.15.x since 5.15.3) on 2022-05-19: https://code.qt.io/cgit/qt/qtwebengine-chromium.git/log/?h=87-based That is only 1 to 1½ months later. The release has been tagged in Qt git on 2022-06-06: https://code.qt.io/cgit/qt/qtwebengine.git/tag/?h=v5.15.10-lts and announced on 2022-06-07: https://www.qt.io/blog/commercial-lts-qt-5.15.10-released That is about 2 months after the upstream Google fixes. So your unqualified "months behind", while technically correct (because 2 is already a plural, at least in English), makes it sound worse than it actually is. The Fedora QtWebEngine updates actually take longer than that to get out (and the upstream and downstream delays add up). The reason it takes time to get security fixes out is because Qt actually maintains stable branches, unlike Google, and backports security fixes instead of forcing everyone to upgrade. Google, on the contrast, deliberately withholds security fixes until a new major version reaches stable, in order to have a levy to force people to upgrade. (The fact that these fixes are not included in the betas, but only dropped into the stable release, also makes the beta testing quite pointless and compromises the stability of the stable releases.) Even a new major Qt release does not ship with the very latest Chromium, but with a bugfixed stable version with already some security fixes backported. (The QtWebEngine Chromium branches are quite similar in spirit to the Firefox ESR/LTS branches.) Qt also does not release a new version every 2 weeks – thankfully, because we are already struggling to keep up with the releases every 2-3 months! I cannot imagine how it would look if we had to ship an update every 2 weeks. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
On 20/07/2022 16:50, Kevin Kofler via devel wrote: There is a lag, but it is less than the average lag we add in Fedora. E.g., the security fixes from Chromium 100 were backported to qtwebengine- chromium git after 1 month, and the release was tagged 2 weeks later. This is not about the Fedora package, but about the QtWebEngine upstream. They are months behind Chromium sources. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
PS: Kevin Kofler via devel wrote: > (*) These features require the KDE KF5/Plasma integration plugin, i.e., > the optional falkon-kde subpackage. Everything else is built-in into > Falkon and/or Qt. The gopher:// example also requires the kio_gopher package, which is not installed by default for obvious reasons. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
Demi Marie Obenour wrote: > What advantage does Falkon have over upstream Chromium? Serious question. Better desktop integration. (Especially KDE Plasma integration, but there is also a gnome-keyring plugin available. The KF5/Plasma integration plugin uses KWallet, of course, but also does other things.) E.g.: * native Qt widgets for everything outside the web view (what the Firefox source code confusingly calls the "chrome" with a small 'c' – perhaps unsurprisingly, I have not seen that term used that way in Chromium code): menu bar, toolbars, tab widget, status bar, dialogs, * native file dialogs wherever Qt has native file dialog support (KDE file dialogs, GTK file dialogs, etc.), otherwise the default Qt ones are used, * a native Qt scroll bar instead of the Chromium one for the site's main scrollbar (somewhat hacky, but usually works), * support for storing passwords securely in KWallet (though sadly as binary blobs and not in the key-value format that KWallet is designed for) (*), * crash handling with KCrash and DrKonqi rather than homegrown Breakpad (*), * additional URL protocols using KIO (e.g., man:, info:, gopher:, etc. – try, e.g., man:grep, info:grep, gopher://gopher.floodgap.com/1/world) (*), * a "Share page" menu using the KDE Purpose Framework (*). (*) These features require the KDE KF5/Plasma integration plugin, i.e., the optional falkon-kde subpackage. Everything else is built-in into Falkon and/or Qt. Even on GNOME, with QGnomePlatform and the falkon-gnome-keyring plugin, Falkon ends up integrating better in some aspects than Chromium or Firefox. I use Falkon as my daily browser. It is normally the only browser I use on my desktop and notebook. (I have Firefox as a fallback, but do not normally need it, because QtWebEngine is 99+% compatible with Chrome.) And my smartphone is a PinePhone running Plasma Mobile, on which I use Angelfish as my one and only browser, a mobile browser also using QtWebEngine. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
On Wed, Jul 20, 2022 17:49:05 +0200, Kevin Kofler via devel wrote: > Hi Ankur, Hi Kevin, > > If you want to go straight for 5.15.10, then the first step would be to get > 5.15.10 into Rawhide, and then go through the same steps above to push > 5.15.10 to the stable releases. Thanks for that. It looks straightforward enough ;) I think I'll start with pushing 5.15.9 to F35/36 first to familiarise myself with the package. Once that's done, we can look at the 5.15.10 update next. I should be able to work on this from tomorrow evening. I'll keep everyone in the loop. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
Hi Ankur,
Ankur Sinha wrote:
> On Wed, Jul 20, 2022 03:58:41 +0200, Kevin Kofler via devel wrote:
>> So, since all current maintainers of qt5-qtwebengine, including me, are
>> failing badly at keeping the package up to date with security fixes, this
>> is an urgent plea for help. The current situation is not acceptable, any
>> helping hands to improve on it would be extremely welcome. I have admin
>> rights to the package, so I can add comaintainers that wish so.
>
> Thanks for maintaining the package. I heavily rely on Qutebrowser, and
> since it depends on qt5-qtwebengine{,-freeworld}, I'll be happy to help
> in whatever capacity I can. I usually use up my Fedora time working on
> our neuro-sig packages, but if it's a few hours every few months to
> update qt5-qtwebengine, I'm happy to help.
Any help you can give is welcome. Time is what we are all lacking, sadly.
But the more we are, the better we can share the load.
> What would the first step to pushing 5.15.9 to F35/F36 be for a start?
The first step would actually be to decide whether to go through with the
5.15.9 update or whether to go straight for 5.15.10. But that would need to
be imported into Rawhide first. So maybe better go with what is already
there (in Rawhide) and building, i.e., 5.15.9.
So if you want to start on 5.15.9, I would say:
1. Check that everything is in shape in Rawhide. I have done a commit a few
hours ago that omits an obsolete patch (that has actually been unnecessary
for years, looking at the code), I guess we can try building that to make
sure that it is still building. (It should. It definitely did build before
my commit.) And also to not break upgrade paths from the releases. If you
can try Qutebrowser and/or Falkon in Rawhide or know someone who can do it
or already did, that would be even better, but we can also do the basic
browser tests on the stable releases once we have the builds for them. As I
wrote, there should theoretically not be any breaking changes in the 5.15.x
LTS series.
2. Sync the current Fedora Rawhide changes to RPM Fusion (Rawhide branch)
qt5-qtwebengine-freeworld. That one is still stuck on 5.15.8. It needs the
update to 5.15.9 and the other changes from Fedora dist-git since 5.15.8
merged, then a build submitted. At least if we can get you commit privileges
to the package there, otherwise Rex or I will have to do that part of the
work.
3. Merge the rawhide branch in dist-git into the f36 and f35 branches, and
submit updates-candidate builds. Wait until they are done. (Better do more
than just grabbing coffee in that time, or you will end up with caffeine
poisoning before the build is done. ;-) Maybe even if you do that with
decaf… ;-) It is a long wait.) Then submit Bodhi updates. I normally disable
automatic pushes and set the limits for manual pushes to the minimum that
Bodhi lets me get away with (should be +1 karma resp. 7 days, unless the
package ended up in the critpath set somehow).
4. Then the merging and building needs to be done also in RPM Fusion, see
point 2. The builds there take even longer (hours), and we will probably
need to do one at a time because there is a shortage especially of aarch64
builders (I believe there is only one beefy enough to accept qt5-
qtwebengine-freeworld at all), and x86_64 builders are also a scarce
resource there.
5. Once karma arrives or the timeout runs out, push the F36 update first,
then the F35 one. (If you have karma only for F36, you can push only that at
first, but you should never push Fn-1 first due to upgrade paths. Though
there can exceptionally be reasons to do so, e.g., if the update needs to go
stable urgently before the release is EOLed.) Then wait for RPM Fusion to
follow suit and/or nag the admins there to push the update, which is a
manual process. Close the occasional bug report about broken dependencies
because -freeworld never hits the mirrors at the exact same time as the
Fedora package. Dependencies protect users from mismatched updates, and
PackageKit will simply silently withhold (not even display) the update for
users with -freeworld installed until both parts are out, but the users
still complain.
Yes, I have deliberately kept the ugly parts of the process in the list. I
hope that this will not demotivate you. (It is what we have to deal with for
every QtWebEngine update.)
If you want to go straight for 5.15.10, then the first step would be to get
5.15.10 into Rawhide, and then go through the same steps above to push
5.15.10 to the stable releases.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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:
Re: Comaintainer(s) wanted for qt5-qtwebengine
On 7/20/22 10:29, Kevin Kofler via devel wrote: > Demi Marie Obenour wrote: >> I can’t help with maintenance, but I honestly wonder if some of >> these programs could be modified to shell out to a browser subprocess. > > That is not a reasonable solution. Those applications need embedded HTML in > the UI, not a separate browser window. And it does not help at all if the > browser that is shelled out to itself uses QtWebEngine. Indeed so :(. I really wish Chromium supported embedding natively. >> Even if Fedora shipped QtWebEngine releases the day they were tagged >> in git, this would still not be enough for security. Not when upstream >> itself is lagging so badly. > > But it would be better than now where we are sitting on dozens of security > fixes, some of them critical, for 3+ MONTHS! Yes, it would be. >> I also wonder if some features of QtWebEngine, such as the V8 JIT >> compiler or even scripting as a whole, ought to be proactively >> disabled. > > -1 to that from me as the maintainer of Falkon. It would completely break > Falkon. Hardly any website these days works without JavaScript > (unfortunately). What advantage does Falkon have over upstream Chromium? Serious question. >> There is absolutely no reason for KMail to be running untrusted scripts, >> and disabling them mitigates many if not most vulnerabilities. > > KMail can (and, I believe, already does) disable JavaScript in its HTML > views. I feel like QtWebEngine should only be used when the scripts being run are trusted. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
Hi Kevin,
On Wed, Jul 20, 2022 03:58:41 +0200, Kevin Kofler via devel wrote:
> So, since all current maintainers of qt5-qtwebengine, including me, are
> failing badly at keeping the package up to date with security fixes, this is
> an urgent plea for help. The current situation is not acceptable, any
> helping hands to improve on it would be extremely welcome. I have admin
> rights to the package, so I can add comaintainers that wish so.
Thanks for maintaining the package. I heavily rely on Qutebrowser, and
since it depends on qt5-qtwebengine{,-freeworld}, I'll be happy to help
in whatever capacity I can. I usually use up my Fedora time working on
our neuro-sig packages, but if it's a few hours every few months to
update qt5-qtwebengine, I'm happy to help.
What would the first step to pushing 5.15.9 to F35/F36 be for a start?
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
Vitaly Zaitsev via devel wrote: > QtWebEngine is an extremely vulnerable thing due to a major lag after > WebKit/Blink security patches. There is a lag, but it is less than the average lag we add in Fedora. E.g., the security fixes from Chromium 100 were backported to qtwebengine- chromium git after 1 month, and the release was tagged 2 weeks later. Note: Do not believe websites when they claim "your browser is outdated and insecure" when using Falkon. They only see the base Chromium version (e.g., for QtWebEngine 5.15.10, that is Chromium 87), not the backported security fixes (5.15.10 includes backported security fixes up to Chromium 100). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
Demi Marie Obenour wrote: > I can’t help with maintenance, but I honestly wonder if some of > these programs could be modified to shell out to a browser subprocess. That is not a reasonable solution. Those applications need embedded HTML in the UI, not a separate browser window. And it does not help at all if the browser that is shelled out to itself uses QtWebEngine. > Even if Fedora shipped QtWebEngine releases the day they were tagged > in git, this would still not be enough for security. Not when upstream > itself is lagging so badly. But it would be better than now where we are sitting on dozens of security fixes, some of them critical, for 3+ MONTHS! > I also wonder if some features of QtWebEngine, such as the V8 JIT > compiler or even scripting as a whole, ought to be proactively > disabled. -1 to that from me as the maintainer of Falkon. It would completely break Falkon. Hardly any website these days works without JavaScript (unfortunately). > There is absolutely no reason for KMail to be running untrusted scripts, > and disabling them mitigates many if not most vulnerabilities. KMail can (and, I believe, already does) disable JavaScript in its HTML views. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
On 20/07/2022 11:57, Fabio Valentini wrote: Just to clarify, epiphany and other GTK- and WebKit-based browsers don't use QtWebEngine, but WebKitGTK. Oops, my mistake. Ofc only KDE/Qt apps is using QtWebEngine for rendering HTML. As far as I know, it doesn't suffer from the same support / late security fixes problem as QtWebEngine, because it's an official WebKit project, and released in parallel with new versions of WebKit. True. WebKitGTK is better maintained in upstream. Telegram Desktop even prefers it despite being a Qt application. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
On Wed, Jul 20, 2022 at 11:04 AM Vitaly Zaitsev via devel wrote: > > On 20/07/2022 08:55, Demi Marie Obenour wrote: > > I also wonder if some features of QtWebEngine, such as the V8 JIT > > compiler or even scripting as a whole, ought to be proactively > > disabled. > > QtWebEngine is an extremely vulnerable thing due to a major lag after > WebKit/Blink security patches. I even decided to build Psi+ client > without WebEngine support. > > But QtWebEngine is also used by GNOME/KDE web browsers (Epiphany, > Falcon). Their users won't be happy after disabling JS engine. Just to clarify, epiphany and other GTK- and WebKit-based browsers don't use QtWebEngine, but WebKitGTK. As far as I know, it doesn't suffer from the same support / late security fixes problem as QtWebEngine, because it's an official WebKit project, and released in parallel with new versions of WebKit. I just noticed that epiphany snapshot builds are even prominently featured in the webkit.org download section :) Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
On 20/07/2022 08:55, Demi Marie Obenour wrote: I also wonder if some features of QtWebEngine, such as the V8 JIT compiler or even scripting as a whole, ought to be proactively disabled. QtWebEngine is an extremely vulnerable thing due to a major lag after WebKit/Blink security patches. I even decided to build Psi+ client without WebEngine support. But QtWebEngine is also used by GNOME/KDE web browsers (Epiphany, Falcon). Their users won't be happy after disabling JS engine. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Comaintainer(s) wanted for qt5-qtwebengine
On 7/19/22 21:58, Kevin Kofler via devel wrote: > Hi, > > QtWebEngine is used as the HTML component for many Qt applications, > including large parts of the KDE software universe. It is used by web > browsers such as Falkon, but also, e.g., by KMail/Kontact. > > The version that is currently (still) used the most is the Qt 5 version. > There is also a Qt 6 version (has been there since 6.2), which is not > currently packaged in Fedora at all. That, too, needs someone to pick up the > work. But most of the relevant applications are still stuck on Qt 5 anyway, > so this message will focus on the Qt 5 version. > > The qt5-qtwebengine package is currently maintained mainly by 2 people: Rex > Dieter (rdieter) and me (kkofler). I used to be the primary maintainer, but > had to resign from that a few years ago due to mainly lack of time. (There > were at the time also some packaging details that I was unhappy with, but > those have all since either been fixed or stopped being relevant. Lack of > time is the big issue that is left.) At that point, Rex Dieter had picked up > the package, but he clearly also lacks the time to really take care of it > (see the evidence below). The package is also open to commits from all @kde- > sig group members, but most of the work is done by the two admin-level > maintainers, i.e., Rex and me. > > Qt releases a security update for 5.15.x every couple months. (There were > around 2 months between 5.15.9 and 5.15.10, around 3 between 5.15.8 and > 5.15.9.) While Qt 5.15.x LTS is mostly commercial-only (with ancient 1-year- > old releases being released under the LGPL), this does not apply to > QtWebEngine, which is based on third-party LGPL code (mostly the WebKit and > KHTML code on which Chromium's Blink is based), and is hence available under > the LGPL from the public git repository. (There are, however, no official > tarballs until 1 year later, so we have a script to roll our own from git. > We need a custom tarball with patent-encumbered stuff ripped out by a script > anyway, so that just makes the tarball generation one more script to run > first.) Since each 5.15.x release includes a whole bunch of backported > security fixes, and not many other changes (should in principle be bugfix- > only), it is imperative to get these out to our users as quickly as > possible. Those security fixes are already delayed by weeks compared to > Chromium upstream, we should not add our own lag to that. > > Now, when we look at how fast (or rather, how slow, sadly) Fedora has been > to roll out qt5-qtwebengine security fixes to users of stable releases, the > results are very disappointing, see: > https://bugzilla.redhat.com/show_bug.cgi?id=2043381 > https://bugzilla.redhat.com/show_bug.cgi?id=2079655 > > The current situation is that 5.15.10 has been tagged in git for almost two > months. Yet, Rawhide is stuck at 5.15.9, and even that has so far not been > pushed to the currently supported stable releases (Fedora 35 and 36), almost > 4 months after it was tagged. > > So, since all current maintainers of qt5-qtwebengine, including me, are > failing badly at keeping the package up to date with security fixes, this is > an urgent plea for help. The current situation is not acceptable, any > helping hands to improve on it would be extremely welcome. I have admin > rights to the package, so I can add comaintainers that wish so. I can’t help with maintenance, but I honestly wonder if some of these programs could be modified to shell out to a browser subprocess. Even if Fedora shipped QtWebEngine releases the day they were tagged in git, this would still not be enough for security. Not when upstream itself is lagging so badly. I also wonder if some features of QtWebEngine, such as the V8 JIT compiler or even scripting as a whole, ought to be proactively disabled. There is absolutely no reason for KMail to be running untrusted scripts, and disabling them mitigates many if not most vulnerabilities. -- Sincerely, Demi Marie Obenour (she/her/hers) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
