Ratchanan,
On Saturday, December 23, 2023 6:53:56 AM MST Ratchanan Srirattanamet wrote:
> 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.
I’m pleased to make your acquaintance.
> 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.
I would agree with that assessment.
> > <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-versio
> ns-to-build-qt-webengine
I am going to copy one sentence from that link in case some people aren’t familiar with it and didn’t bother to click through and read it.
"Building Qt WebEngine with earlier Qt versions (down to the last LTS version) is supported. It means that Qt WebEngine 5.15 can be built with Qt 5.12.x, Qt 5.14.x, and Qt 5.15.”
So, referring back to https://endoflife.date/qt, any version of Qt WebEngine 5.15 should be able to build against any earlier 5.15 release (which was the case when I just backported Qt WebEngine 5.15.15 to stable, which mostly contains Qt 5.15.8).
https://salsa.debian.org/qt-kde-team/qt/qtwebengine/-/merge_requests/23
In a hypothetical world where Qt 6.2 LTS had shipped with bookworm, we could build any Qt WebEngine from 6.2, 6.3, or 6.4 against it without problem. Initially it might seem best to build the highest possible, but because 6.4 updates end a full year before 6.2 LTS updates, it would be best for stable support if we stuck with 6.2 as long as possible.
When 6.2 LTS reaches EOL in 2025, there are two possible paths forward. The first would be to try to backport Qt WebEngine 6.5 LTS to build against Qt 6.2. This might be simple or it might be complex, depending on which parts of Qt have changed between LTS releases. But once it has been done for one version of Qt WebEngine (say, for example, Qt WebEngine 6.5.8) it should be easy to apply to all future point releases in the 6.5 series.
If it ends up not being feasible to backport the entire Qt WebEngine from the next LTS release, then we could look at cherry-picking all of the security commits. This would be, by far, the most time-intensive solution. But, as your point out, the security fixes on the Chromium side are well marked. And, generally, they are small commits that only modify a few lines. For example:
Every once in a while, a commit is much more invasive:
--
Soren Stoutner
Attachment:
OpenPGP_0x2D48F45A7EBE8C12.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature