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@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 on the list, report it: https://pagure.io/fedora-infrastructure
