Hello,
I'm Ratchanan Srirattanamet, and I'm a "maintainer" of the QtWebEngine
for Ubuntu Touch (I usually pull from Debian unstable and add our
patches). As such, I have a few insights and ideas regarding this.
On 07-12-2023 18:49, Soren Stoutner wrote:
> If this is deemed inappropriate for stable-security, it might be
> possible to cherry-pick just the security updates from the Qt
> WebEngine LTS releases and manually apply them to the current tarball
> in stable. Is anyone familiar with how well documented Qt’s commits
> are as to which are security related and which are not?
At least for the Chromium side, for between a QtWebEngine patch versions
(where the Chromium base has not been updated), The Qt Company tags the
backported commits from Chromium with "[Backport] CVE-such-and-such" or
"[Backport] Security bug <number>". Commits usually appear in the
qtwebengine-chromium before the release time, so for certain grave issue
one can cherry-pick a commit from qtwebengine-chromium side of thing and
apply to Debian packaging. Obviously that depends on The Qt Company
deciding to backport such commit/fix from Chromium in the first place,
which might not happen in a timely manner.
That said, I don't see such tagging on the Qt-side qtwebengine
repository. So if a vulnerability appears on that side it could be more
difficult to identify. And I still think it's better to just include the
whole new version of QtWebEngine rather than cherry-picking certain patches.
> <snip>
>
> 4.
> It has been suggested that security support in stable might be
> provided through stable-backports instead of stable-security. For LTS
> releases this should be fairly simple (assuming the problems with
> private headers described in point #1 above are resolved). For non-
> LTS releases this could become overly complex because a newer version
> of Qt WebEngine probably requires backporting every Qt and KDE
> package, which feels unmanageable
Qt actually allows building QtWebEngine with an earlier Qt versions
(down to the last LTS release) [1]. We are doing this all the time; what
Mike Gabriel didn't mention is we're still based on Qt 5.12.8 shipped in
Ubuntu 20.04, which means we build QtWebEngine 5.15.x line against Qt
5.12.8 with no problem whatsoever (in practice we have to patch
QtWebEngine a bit in the documentation building part). At one point in
time, we even used to build QtWebEngine 5.14.x line against Qt 5.9.x
with a relatively minor patching. So, there's really no need to backport
the rest of Qt and KDE stack in order to provide a more up-to-date
QtWebEngine (or stick with LTS Qt in stable), except for maybe QtWebView
and Angelfish.
If you're willing to do a bit mind-bending, it might even be possible to
stay with the LTS release of QtWebEngine while upgrading the rest of the
Qt stack up. Can't say if that is desirable though. :D
[1]:
https://doc.qt.io/qt-5/qtwebengine-platform-notes.html#using-earlier-qt-versions-to-build-qt-webengine
---
Ratchanan Srirattanamet
