Currently security patches to Qt WebEngine are not uploaded to Debian stable.
The purpose of this bug report is to track efforts to change that.

The purpose of this email is to coordinate efforts to get proper security
support for Qt WebEngine into stable.  This is a much more complicated topic
than initially meets the eye, and doing it well requires coordination
between a
large number of disparate parties to make sure that we are aware of how Qt
WebEngine is used and to make sure that plans for maintaining security
support
in stable does not have adverse affects.

There is a tracking bug for this issue at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057755


BACKGROUND
============

First, some general background.  Qt WebEngine is a highly modified
rolling fork
of Chromium.  It is produced by The Qt Company as part of the the Qt
Framework.
KDE is built on top of Qt, but there are also other programs in Debian
that use
Qt without KDE.

Debian currently ships Qt 5 and Qt 6, so there are two separate
WebEngines that
need security support in stable.  At the time of this writing, stable has
qtwebengine-opensource-src 5.15.13+dfsg-1~deb12u1 (bullseye was originally
released with 5.15.12+dfsg-3) and qt6-webengine 6.4.2-final+dfsg-1.

https://tracker.debian.org/pkg/qtwebengine-opensource-src

https://tracker.debian.org/pkg/qt6-webengine

Qt considers some releases to be LTS (Long Term Support).  Qt 5.15, 6.2,
and 6.5
are LTS releases.  Typically LTS releases get security support for three
years,
although 5.15 has extended support because of its transitional status.

https://endoflife.date/qt

Qt 6 usually releases an update every couple of months, with Qt 5 at a
slower
pace planned at about every 6 months.

https://wiki.qt.io/Qt_5.15_Release

https://wiki.qt.io/Qt_6.5_Release

Because of the significance of the changes Qt makes to their rolling fork of
Chromium, Qt WebEngine is significantly behind upstream Chromium from a
feature
perspective.  It takes a while to bundle up all those changes and test
them to
make sure they work.  However, each release should be up-to-date from a
security
perspective as of the date of their release.  From the link below, "the
Chromium
versions here are just the base versions. Security patches are
backported from
the most recent Chrome releases, to all supported versions.”

https://wiki.qt.io/QtWebEngine/ChromiumVersions

It should also be noted that not all security bugs in Chromium affect Qt
WebEngine, depending on if the bug is in a part of the source code that Qt
WebEngine uses in an unmodified way.


MOTIVATION
===========

The main thrust of my desire at this point it to make sure that security
patches
in official Qt WebEngine releases make it into stable.  A different
conversation, worth having in the future, would be the cherry-picking of
significant Chromium security patches and applying them to Qt WebEngine in
Debian in the interim between Qt WebEngine releases (a couple of months is
sometimes too long to wait for a security fix).

Qt WebEngine is often used to display program documentation.  For example, I
believe the KDE Help Center uses Qt WebEngine to render content. Security
concerns with this are small, as the content is trusted and shipped in the
Debian packages.

Qt WebEngine can also be used to render untrusted content.  For example, I
believe the KMail uses Qt WebEngine to render HTML content in emails.  The
security concerns in these scenarios are greater, because the content
might be
malicious.  KMail does have some protection against compromise in the
form of
not rendering HTML content by default, but security concerns remain when Qt
WebEngine is not properly patched.

The greatest concern for timely security updates is when Qt WebEngine is
used as
the rendering engine in a web browser.  This is my personal motivation for
seeking security support for Qt WebEngine in stable.  I am both the upstream
developer and the Debian package maintainer for Privacy Browser.

https://tracker.debian.org/pkg/privacybrowser

The following are also browsers in Debian that use Qt WebEngine to render
content:  Konqueror, Falkon, Angelfish, Morph Browser, qutebrowser. 
There might
be others that I am unaware of.  I would not be comfortable recommending
someone
use Privacy Browser on Debian stable unless they were receiving security
updates
to Qt WebEngine.  I have included the maintainers of these other browser
packages on this email, presuming that they feel the same way.


COMPLEXITIES
============

1.
I have been told that Angelfish uses a private header inside of Qt
WebEngine.
This would cause problems if that private header or its behavior is
modified by
a security patch.  Currently Qt 5 WebEngine artificially increments its
ABI with
every release to force Angelfish to rebuild against it to make sure that
nothing
breaks. Could one of the maintainers of Angelfish give us a little more
background about which private header is used and for what purpose. 
Obviously,
it would make security support in stable much easier if we were able to
find a
way for Anglefish to not use a Qt WebEngine private header, but at a
minimum, if
we had documentation about what was used and why, we could check each
release in
advance to make sure that particular private header wasn’t affected, and
only
deal with the ABI change in instances where it mattered.


2.
Qt includes both security fixes and some bug fixes in their LTS releases
(but
not new features).  For example, here is a non-security bug that I
reported to
Qt which was fixed in the the Qt 6 series but was also backported to
5.15 LTS.

https://bugreports.qt.io/browse/QTBUG-104869

I know that generally the security team likes security updates to only
include
security fixes.  How amenable would you be to including the entire
upstream Qt
LTS releases in stable-security or stable-updates?  I know that you
sometimes
make exceptions, as in the case with Chromium, which currently releases the
entire new upstream code to stable-security, including feature updates.

https://tracker.debian.org/pkg/chromium

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?  My guess is that this would be a time consuming process and it
runs
the risk that something with security implications is missed in stable,
providing a sense of false security to users who assume they are
protected using
the stable packages.


3.
Qt generally only provides LTS support for three years. Currently, the
Qt 6 LTS
release is 6.5, with support ending on 31 March 2026 (see the link above
about
end-of-life dates).  Note that generally Qt requires a commercial license to
access support for the full LTS time period, but Qt WebEngine has LGPL
dependencies which require them to provide the source code for that
component
as described at the link below:

https://lists.qt-project.org/pipermail/development/2023-October/044573.html

The timing of this release and its overlap with Debian’s release cycle could
possibly cause problems.  For example, in the past, Qt LTS releases have not
always been the ones that are included in Debian stable.  Bullseye
released with
Qt 6.4.2, which was not an LTS release and for which security support
ended 8
months ago.

Qt LTS releases tend to come along every year and a half or so (halfway
through
the previous LTS), so if we timed everything perfectly, and if the
freeze isn’t
too long, we should usually be able to get a Qt LTS release that covers
at least
most of stable’s typical 2-year lifecycle.  Doing so would probably
require only
packaging Qt LTS releases in unstable, or at least preventing non-LTS
releases
from migrating to testing.  This might cause a lot of consternation among
dependent packages that don’t want to wait for newer features that come out
between LTS releases.  For the Qt and KDE maintainers, how feasible
would it be
to always make sure an LTS release of Qt is what is shipped in stable
releases?


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 (building Qt WebEngine requires
compatible versions of much of the rest of the Qt Framework, and
updating those
would affect all other packages that use Qt or KDE even if they don’t use Qt
WebEngine directly.)


CONCLUSION
===========

Security support for Qt WebEngine in stable is something that, as far as
I know,
has never been addressed before in Debian, probably because of the
complexities
of making it happen and the large number of people who would need to
coordinate.
I am willing to dedicate time to the ongoing maintenance of security
support as
long as the workload is reasonable and we can come to an agreement of how it
should be implemented.

Hej,

Am Freitag, 8. Dezember 2023, 02:49:56 CET schrieb Soren Stoutner:
[...]

Probably not very feasible.

One issue is that Debian & Qt have different release schedules. Debian
releases happen roughly every 2 years whereas Qt LTS releases happen
every 18 months (if they keep the schedule).
That means that it aligns well for some releases (like trixie), but
badly for other releases. In the worst case, Qt could be close to 2
years old when Debian is released if we stick to LTS releases.

Another complication is that the KDE regularly requires quite recent
versions of its dependencies. The KDE 6 megarelease in February requires
Qt 6.6 and has done so since the first alpha release. In other words, a
6-months old LTS Qt was already too old.
If we have to stick to old KDE versions, the entire KDE stack might be
out of support before Debian even gets to its first freeze.

Patrick,

Qt has LTS releases about every 18 months and supports them for 36 months (three years).
This means there are always two active LTS releases.  Unless there is an unusually long
freeze, stable should end up with a release that has somewhere between 1and 2 years of
support.  It might not be perfect, but it is a lot better than what we currently have.

The transition to KDE 6 is a bit of a unique situation.  I would imagine that it would need to
mature a bit before most people want to be using it (thinking of the old KDE 4 transition, or
even the one to KDE 5).  By the time KDE 6 is ready to propagate to stable, I would imagine
that there will be a version that is based on an LTS release of Qt.

Looking at KDE’s release information, I see that KDE has an LTS release about 1-2 years.  I
am assuming these KDE LTS releases are compatible with Qt LTS releases, although if
anyone has any information to the contrary please share.

https://community.kde.org/Schedules/Plasma_5[1]

https://endoflife.date/kde-plasma[2]

How feasible would it be to make sure that stable always ships with paired LTS releases of
KDE and Qt?  As you point out above, those release windows might not line up exactly with
Debian’s release window, but it seems like it would be an improvement on the current
situation.  Beyond security support issues, there would probably be a lot of stability
benefits (like KMail not breaking as often).

If you don’t think it is feasible to ship LTS versions of KDE and Qt in stable, how do you
propose handling proper security support for KDE and Qt?

--------
[1] https://community.kde.org/Schedules/Plasma_5
[2] https://endoflife.date/kde-plasma

Hej Soren,

Am Mittwoch, 13. Dezember 2023, 22:19:04 CET schrieb Soren Stoutner:
[...]

Don't forget that the open-source Qt LTS releases are delayed by a year.

The release schedule for Plasma 6 is not set in stone yet, but the
earliest they can base it on a Qt LTS would be in about a year.
Let's see how that lines up with trixie.

KDE doesn't have LTS releases, only Plasma has.

If Plasma 6 continues the path of Plasma 5, they'll have LTS releases
every 2 years, namely early in even years so that it fits with the Ubuntu
LTS release among other things. And that is quite a bad fit for Debian.
[Plasma 5.27 in bookworm is an outlier. It was made LTS because it is
the last Plasma 5 release.]

KDE used to support Plasma LTS releases for about 18-20 months. That
meant that by the time of a Debian release, the LTS release is almost
out of support. And yes, support for an LTS version stops several months
before the next LTS version is released.

There is no LTS version of Kmail. Neither the Frameworks nor KDE Gear
have LTS versions. By the time of a Debian release, both are already out
of support.

I can only do with what I have. If you want better support, you need
more resources.

Patrick,

I wasn’t aware of that.  Can you please elaborate on how that timeline works?
One of the things I am hoping to accomplish with this bug report is to collect
all the information that everyone has regarding this issue in one place to
make it easy for others to find it in the future.

My understanding is that LTS releases for Qt WebEngine are not delayed because
the AGPL license doesn’t allow it.

I didn’t know that either.

Debian stable tends to release in the summer of odd years and Ubuntu LTS tends
to release in the spring of even years.  If KDE synchronizes their schedule to
release at the beginning of even years to make it easier to be packaged into
Ubuntu LTS releases, that makes we wonder how many other projects also
synchronize their release schedules to make it easier for Ubuntu.

Perhaps there are really good reasons for not doing so, but would it be in
Debian’s interest to change our release schedule to be in the summer of even
years?  If other projects besides KDE coordinate their LTS releases around
even years, then it might make the lives of many package maintainers easier.

It seems to me that shipping LTS releases of KDE Plasma and Qt in stable would
require less effort, not more.  It would require less packaging of intermediate
releases (because I assume packaging an LTS point release would take less
effort than releases that had feature changes).  Other KDE components, like
KMail, could be packaged up to the latest versions that build on top of the
LTS releases.  And even though KMail doesn’t have an LTS release, it would
benefit from stable security updates to Qt WebEngine.

What's the benefit of using upstream-supported LTS releases?
Debian stable would would anyway not follow upstream point releases
with rare exceptions like browser engines.

Backporting CVE fixes for these packages, as has already been done for
many years.

Except for the browser engines, CVEs have been few and fixes easy to backport.

Security support for the 3 years non-LTS support of Debian stable
releases is not realistically possible for Qt WebEngine unless this
is offered by upstream in an API/ABI compatible way without requiring
newer dependencies (WebKitGTK has such upstream support).

cu
Adrian

Adrian,
Chromium.  It is packaged as part of Qt, which is the basis of KDE.

Qt WebEngine is used as the browser engine for the following browsers in
Debian:  Konqueror, Falkon, Angelfish, Morph Browser, qutebrowser, Privacy
Browser.

It is also use to render HTML content in KMail and Akregator.  It is used by
Marble, Quassel, ghostwriter, and a host of other programs that need to
display HTML content.

Currently there is no real security support for Qt WebEngine in stable, which
is an oversight that might surprise many Debian users.  The purpose of this
discussion is to figure out the best way to change that.  Shipping LTS versions
of Qt in stable would put us in a better position than the status quo, even if
it doesn’t get us all the way there.  And based on what Patrick said, it
sounds like shipping LTS versions of KDE Plasma would make it easier to ship
LTS versions of Qt.

Hi Soren,
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#limited-security-support
so I wouldn't call it an oversight.

Paul

Paul,

Point taken.

How do you recommend we change that?

Hi everyone,

AFAIK, QtWebengine is not affected by the one-year-delay-release
policy. In Ubuntu Touch (i.e. Morph Web Browser) we currently also use
QtWebEngine (Qt5 version).

For Ubuntu Touch we regularly bump to a latest QtWebEngine 5.15.x
release. Problems is that it is based on a very old version of the
Chromium webengine (receiving security support, but not progressing
forwards).

To switch to a latest chromium engine one needs to build ones browser
software against the Qt6 variant of QtWebEngine (this is planned for
Ubuntu Touch, but no ETA, yet).

All in all, I dearly welcome Soren's initiative on turning QtWebEngine
5.x and 6.x into rolling release packages inside Debian as the Morph
Web Browser (morph-browser by package name) heavily will benefit from
this.

In the past QtWebEngine has received totally different release
management compared to Qt core components. So possibly, none of this
applies to QtWebEngine.

Off topic here. Debian can't synchronize with all upstreams the ship
software of nor can upstreams synchronize with Debian. In theory, this
is possible, but we in Debian should find workflows that fit with all
upstreams. And yes, sometimes its painful missing an upstream release
by 2 months because of Debian's freeze policy shortly before a Debian
release.
LTS upstreams is always a good choice for massive packaging projects
(i.e. when many many packages are involved). This applies to Qt and
KDE/Plasma I guess.

Greets,
Mike

Hi Soren,

I think you're having the right discussion. I'm not a Stable Release
Manager so I don't feel authoritative about stable. However, in my
*personal* opinion and reflected in a proposal [1] I'm driving (about
changes during the freeze, so targeting unstable and testing), we could
be accepting more new upstream release *if* upstream release processes
and criteria align with our stability criteria. In nearly all cases I
expect that to mean a stable branch with strict documented rules and QA
processes to guard quality.

Paul

[1]
https://salsa.debian.org/elbrus/memos/-/blob/main/vetted-upstream-stable-versions.md

This is not a new discussion, and there aren't any simple solutions.
The release notes for squeeze[1] released nearly 13 years ago already
had a section on limited support for browser engines.

For web browsers, shipping the latest versions is the only workable solution.

WebKitGTK is basically the GNOME equivalent of Qt WebEngine based on a
different browser. Security support for WebKitGTK was also missing for
many years, it became feasible when upstream made commitments regarding
API/ABI compatibility and sticking to using older versions of dependencies.

Qt has nearly 30 years history of being somewhere between open source
and freemium,[2] this is not an upstream one would expect to make such
commitments.

When a suitable version is available updating in (old)stable might be
possible, e.g. updating qtwebengine-opensource-src in stable and
oldstable might be technically feasible and rebuilding angelfish would
be unlikely to be a dealbreaker if someone wants to discuss such a
(tested!) update with the release team. The release team might or might
not agree with such an update, but this would not be the same as
providing security support for qtwebengine-opensource-src.

Your "better position" might actually be worse, far more surprising than
flagging something as unsupported from the beginning would be declaring
it supported and then dropping support after a year - what are users
supposed to do at that point?

cu
Adrian

[1] https://www.debian.org/releases/squeeze/amd64/release-notes.en.txt
[2] https://en.wikipedia.org/wiki/Qt_(software)#History_of_Qt

On Thursday, December 14, 2023 12:58:02 AM MST Mike Gabriel wrote:

 > All in all, I dearly welcome Soren's initiative on turning QtWebEngine

 > 5.x and 6.x into rolling release packages inside Debian as the Morph

 > Web Browser (morph-browser by package name) heavily will benefit from

 > this.

 >

 > Responding to Qt core related thoughts only with this: Sticking with

 > LTS upstreams is always a good choice for massive packaging projects

 > (i.e. when many many packages are involved). This applies to Qt and

 > KDE/Plasma I guess.

Qt WebEngine is a particularly difficult problem to solve as compared with other
browser engines in Debian, because it is so intricately connected to so many
other packages. In the case of Chromium, the latest full upstream release is
just uploaded directly to stable-security and oldstable-security.

https://tracker.debian.org/pkg/chromium <https://tracker.debian.org/pkg/chromium>

In the case of Firefox, the ESR (Extended Support Release) is used, but that is
only maintained for 15 months. When an old ESR is retired, a new one is uploaded
to stable-security, oldstable-security, and old-oldstable-security, included all
the new features.

https://tracker.debian.org/pkg/firefox-esr
<https://tracker.debian.org/pkg/firefox-esr>

They can do this because installing new feature releases of these packages does
not break other packages.

WebKitGTK also uploads the current upstream version to stable-security and
oldstable-security, including all feature updates. From what has been said in
this thread, that is because upstream WebKitGTK is handled in such a way that
these feature updates do not break compatibility with the GTK programs that
incorporate WebKitGTK.

https://tracker.debian.org/pkg/webkit2gtk
<https://tracker.debian.org/pkg/webkit2gtk>

Security support for Qt WebEngine does not enjoy this simplicity, which is why
all previous discussions about how to manage security support in stable have
ended without a fruitful resolution.

For all who have not already done so, I would recommend taking a look at the LTS
release chart in the graphic at the top of this URL:

https://endoflife.date/qt <https://endoflife.date/qt>

LTS releases are supported for 36 months and are released every 18 months. LTS
point releases tend to drop about every 3 months.

I propose the following plan for security support in stable.

1. Always maintain the latest Qt LTS release in testing.

2. When stable is released, Qt WebEngine LTS point releases can be uploaded to
stable. It should be possible to do this without updating the other aspects of
Qt LTS in stable and without breaking all the KDE packages that depend on Qt
WebEngine.

3. When the LTS in stable is no longer supported, security patches can be
backported from the current LTS to the one in stable.

This sounds like a doable amount of security work and I would be willing to
undertake it. I would be even more pleased to manage this as a team, especially
when handling critical, time-sensitive vulnerabilities.

Given Qt’s LTS release schedule and how it will align differently with Debian
for each release, this means that stable should have somewhere between 1-2.5
years of upstream LTS support (easy updates without backporting at Debian’s level).

This plan does not address oldstable security support. I would be willing to be
involved with that if there were a team that wanted to share the load.
Otherwise, we could modify the existing release security statement to inform
users that there is no expectation of Qt WebEngine security support in oldstable.

The biggest downside to this plan is that it limits the recentness of the KDE
software that can be included in testing and stable. So far, I have not been
able to find good documentation showing what the minimum Qt dependency versions
are for each release of KDE. Previously I discussed using KDE Plasma’s LTS
release, but a better way to handle things might be to use whatever the highest
KDE release is that can be built against the latest Qt LTS.

Paul,

That is an interesting idea that I could see improving both the release
process and the quality of the software that ends up in stable.

Non-LTS oldstable is the 3rd year of stable security support,
this is required for giving users time to schedule the invasive
upgrades to a new Debian stable at a convenient time.

LTS oldstable (after regular security support has ended) is a paid
endeavour outside the scope of what Debian volunteers are expected
to support.
grasp why browser engines are considered unsupportable.

In recent years, chromium had on average more than 1 CVE per day:
https://security-tracker.debian.org/tracker/source-package/chromium

cu
Adrian

On Thursday, December 14, 2023 4:19:17 PM MST Adrian Bunk wrote:

 > Non-LTS oldstable is the 3rd year of stable security support,

 > this is required for giving users time to schedule the invasive

 > upgrades to a new Debian stable at a convenient time.

 >

 > LTS oldstable (after regular security support has ended) is a paid

 > endeavour outside the scope of what Debian volunteers are expected

 > to support.

That is a good point. However, I consider full coverage of security support for
stable to be an improvement over the current situation. Explicitly stating that
security support is not shipped for oldstable does not do any more harm to users
than what we currently do by explicitly stating that security support is not
shipped for either stable or oldstable.

 > By calling this "doable" you are demonstrating that you do not fully

 > grasp why browser engines are considered unsupportable.

 >

 > In recent years, chromium had on average more than 1 CVE per day:

 > https://security-tracker.debian.org/tracker/source-package/chromium

That is true. However, not all of those bugs apply to Qt WebEngine. The latest
LTS point release of Qt WebEngine 5.15.16 was comprised of 11 commits.

https://code.qt.io/cgit/qt/qtwebengine.git/log/?h=5.15.16
<https://code.qt.io/cgit/qt/qtwebengine.git/log/?h=5.15.16>

Some of them don’t have any security implications. The following commits do
(some with CVEs and others without).

https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=e658807b3f7329160f0017d282aaa280a90e515d
<https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=e658807b3f7329160f0017d282aaa280a90e515d>

https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=290b790fc48fbf4202f169cb95158891eb78d281
<https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=290b790fc48fbf4202f169cb95158891eb78d281>

https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=00c524f3a8c164aed4eaee203f151fb18d5c4e90
<https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=00c524f3a8c164aed4eaee203f151fb18d5c4e90>

https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=fce588d26d0f064e899f6d56a6b793d73c68abd3
<https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=fce588d26d0f064e899f6d56a6b793d73c68abd3>

https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=ba72ade84f39d82adee1c4a0a4b9c171cd390a7e
<https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=ba72ade84f39d82adee1c4a0a4b9c171cd390a7e>

https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=224806a7022eed6d5c75b486bec8715a618cb314
<https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=224806a7022eed6d5c75b486bec8715a618cb314>

In addition, this commit checks for an important potential compatibility issue
with recent versions of FFMpeg:

https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=855806fefdd52b29e8b15b6a02e263afc21028c8
<https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.16&id=855806fefdd52b29e8b15b6a02e263afc21028c8>

A number of these patches would apply to an older LTS without modification. Some
would need minor modifications. Some would not apply to an older LTS because
they are fixing problems in features that were released after the LTS. And some
would require significant effort to backport.

Additionally, a number of recent high-profile Chromium vulnerabilities have been
in third-party libraries and not in Chromium itself. For example, libtiff:

https://bugs.chromium.org/p/chromium/issues/detail?id=1399080
<https://bugs.chromium.org/p/chromium/issues/detail?id=1399080>

libwebp:

https://www.rezilion.com/blog/rezilion-researchers-uncover-new-details-on-severity-of-google-chrome-zero-day-vulnerability-cve-2023-4863/
<https://www.rezilion.com/blog/rezilion-researchers-uncover-new-details-on-severity-of-google-chrome-zero-day-vulnerability-cve-2023-4863/>

I have been working recently in getting Qt WebEngine to build using system
copies of libraries instead of the bundled versions. This often involves
coordinating efforts with upstream Qt and Google. For example, in the case of
libtiff, Chromium was using a private header, which made building against the
system library unfeasible. That problem is now fixed upstream.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033747
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033747>

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033749
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033749>

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038123
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038123>

Any of these patches that fix bundled third-party libraries that we aren’t using
don’t need to be backported because they will be handled by the updates that are
applied by those library package maintainers.

Considering all of the above, handling security support in stable would
obviously be a lot of work, but to me it feels like it is in the realm of what
is doable. Particularly if there was assistance by a team of interested people.

I would like to offer my (outsider) perspective as the Debian
WebKitGTK / WPE WebKit maintainer.

I'm not too familiar with the Qt, KDE or Chromium release cycles, but
having that in mind I think that although I welcome the efforts to
provide security support to the Qt WebEngine I also share Adrian's
concerns that this is probably not going to be an easy task.

For reference, in the case of WebKitGTK, and as it was correctly
pointed out, Debian didn't provide security support for a long
time. We started talking about it ages ago but it took years of work
before it finally happened.

Off the top of my head:

- The project created a policy to support Debian and Ubuntu LTS by not
  bumping the dependencies:

https://docs.webkit.org/Ports/WebKitGTK%20and%20WPE%20WebKit/DependenciesPolicy.html

  We had the explicit goal to support those distros, I was part of
  those conversations.

  This was coordinated with Apple so they e.g. would not start using
  too recent C++ features that would require us to use a new compiler.

  In practice WebKitGTK would continue working for a while after the
  officially supported period (we were still providing security
  updates for buster during H1 2023).

- Strong API / ABI stability. Although we don't have LTS releases any
  stable WebKitGTK build works with any app linked against an earlier
  version. If some of the basic dependencies have a major API / ABI
  break (soup2 -> soup3, gtk3 -> gtk4) we keep supporting the old
  versions for as long as it's feasible. We currently have three
  different sets of binary packages from the same sources so older
  apps can still use the latest WebKitGTK packages.

- WebKitGTK and WPE publish security advisories, thanks also to the good
  relationship that we have with Apple, which allows us to have
  up-to-date information about the CVEs that affect us.

- Before having official security support in Debian we were providing
  stable updates via backports starting from jessie. It wasn't until
  buster (3-4 years later) that WebKitGTK got officially supported,
  thanks also to the good track record of security updates that Ubuntu
  had due to the great work of Jeremy Bicha.

- And even with all that in our favor, keeping WebKitGTK up-to-date
  and properly supported is not a trivial amount of work, and we could
  also not avoid having the occasional regression, sometimes our fault
  (#1035469) and sometimes due to problems in other packages
  (#1054150).

If you still want to give it a go maybe try updating the Qt WebEngine
via backports first, although if that requires that the Qt / KDE
maintainers stick to a specific LTE branch then you need to coordinate
that with them first.

One last thing: when you say "When the LTS in stable is no longer
supported, security patches can be backported from the current LTS to
the one in stable" I think you might be underestimating the complexity
of doing that. Web engines are extremely active projects (WebKit has
some 50 commits per day, and if I'm reading GitHub's numbers correctly
Chromium has 10 times more). Identifying and backporting the security
fixes (of which Chromium has a lot) is not a joke.

And I think that's all from my side, I hope this was useful.

Regards,

Berto

From a policy point of view, the duration of security support is a
Debian-wide policy and not a per-package policy.

From a user point of view, an organization/company running Debian on
their user/employee desktops would not schedule upgrades to a new
stable on release day - 1 year of migration time is really necessary.

From a security point of view, providing updates would be an improvement.
E.g. upgrading Qt5 WebEngine in bullseye and bookworm to 5.15.15 in
point releases might already be an option.
But that's different from calling something security supported, which
could do more harm than good by giving users a false sense of security
instead of looking for alternatives.

Part of the problem is that "some would require significant effort"
might end up meaning that 5% of the CVEs take 95% of the time.

There might be a 0-day vulnerability that is already being exploited by
nation-state actors where they had to rewrite half the browser to fix it.

Providing security support by backporting fixes to Qt WebEngine feels to
me more like in the realm of one full-time employed Blink engineer.

It would be both a lot of work and requires relevant skills from the
people doing it.

For trixie, you would need people who reliably commit in 2024 to doing
a lot of work in 2026-2028.

Even your "no support for oldstable" would keep you busy in the first
half of 2027. What is your track record in Debian of still being active
several years later?

You are also vastly overestimating the number of people available for
such work in Debian. Debian has few very active people, sometimes
literally (co)maintaining > 1000 packages, but most people are only
maintaining one or few packages. Qt6 has ~ 2 active maintainers,
and many key areas/packages of Debian have a single person.

Realistically, your effort would be a team with one member.

cu
Adrian

We already set some tighter deadlines, Chromium security support will
also end six months after the release of the next stable release.

But I agree with the general sentiment that this too much work to directly
commit to full security support. A first step would be to initially commit
to rebase to the latest LTS release in every point release. That would already
be an improvement.

Cheers,
        Moritz

Alberto

Thanks for that perspective.  It is very informative.

What WebKitGTK has accomplished is impressive.  Specifically, that you are able
to release updated packages, including feature updates, cleanly into stable
and oldstable.  As you point out, doing so with Qt WebEngine would require
significant changes to the way upstream works.

Luckily, my intentions are much less ambitions.  I would julst like to handle
security support for stable without adding full new feature releases.

I think this is the best way forward.  Bookworm released with an LTS version
of Qt 5 and a non-LTS version of Qt 6.  It seems it should be fairly easy to
start maintaining proper security support for Qt 5 WebEngine through
backports.  If we can get trixie to release with an LTS version of Qt 6, we
can then maintain security updates for both versions of Qt.  Based on how well
that works, we can then evaluate using the standard security infrastructure to
handle these instead of backports.

Something similar has already been done once through a stable point release.
Bookworm released with qtwebengine-opensource-src 5.15.8+dfsg-1, but
5.15.13+dfsg-1~deb12u1 was later uploaded.  Perhaps Dmitry could provide some
insight into the motivation behind the update and any difficulties that were
encountered.

At this point, the biggest remaining question is what is the private header
that angelfish is using in Qt WebEngine and why?  Can one of the angelfish
maintainers or someone else familiar with the reasoning provide an
explanation?

Thanks,

Soren

That's not true, bookworm released with 5.15.13+dfsg-1~deb12u1.

No matter what angelfish does, qtwebview-opensource-src will in any case
also need a rebuild.

cu
Adrian

How does stable initially release with an ~deb12u1?

Qt WebView is deprecated upstream.  It was based on the same Apple WebKit
source that WebViewGTK uses.  It was replaced quite a while ago by Qt
WebEngine, which is based on Google’s Chromium.  There is no Qt 6 version of
Qt WebView, so it will go entirely away at that point.

But this brings up an interesting question.  Why are the Qt source packages
building private-dev binary packages?  There was probably some historical
reason for doing so, but handling security support in stable would be a lot
easier if we stopped shipping private headers that other packages can build-
depends on.  Perhaps Dmitry or Patrick could provide some background.

Hej,

Am Sonntag, 17. Dezember 2023, 00:33:58 CET schrieb Soren Stoutner:
[...]

Are you perhaps confusing Qt WebView with Qt WebKit ?

Usually, we try to avoid packaging the private headers. But for some
packages, we just need to. And that's because other packages depend on
them incl. other Qt submodules.
We don't have a rule set in stone, but we usually package private
headers when either another Qt submodule needs them (e.g. qtwebview
needs the private headers of qtwebengine, hence we package them) or when
important KDE components need them (e.g. qtwayland).

Yes, that was exactly my confusion.  Sorry for reading it wrong.  Qt WebView
is the QML wrapper for Qt WebEngine.  And there definitely is a Qt 6 WebView.

Looking at the list of private header files that ship in qtwebengine5-private-
dev, these all relate to the Qt specific bindings on top of the Chromium source
code (these are the Qt specific APIs that are then translated into Chromium
calls).  None of Chormium’s private headers are exposed, meaning that none of
the private headers that are involved in the rendering or processing of
websites are included.  It is nearly unthinkable that any of these Qt specific
headers would be modified by a security update.  So, it should generally be
possible to ship Qt WebEngine LTS updates without creating any problems for
packages that built against these private headers.

Digging into this a little further, it looks like the current version of Angelfish does not use
any Qt WebEngine private headers (qtwebengine5-private-dev is not listed as a build-
depends).

https://tracker.debian.org/media/packages/a/angelfish/control-22.11-1[1]

I had previously been told that Angelfish was using private headers by one of the Qt
WebEngine packagers.  Perhaps it did so at some time in the past, but it doesn’t appear to
be a problem any longer.

Now that is all cleared up, I think that next week I am going to build the current version
of Qt 5 WebEngine for stable and test it on a system I have running locally, focusing
specifically on all of the browsers that use Qt WebEngine.  If all seems to work well, would
anyone have any objections to me uploading it to bookworm-backports?

--------
[1] https://tracker.debian.org/media/packages/a/angelfish/control-22.11-1

I don't know what's going on with the headers, but there is a reason why
the dependency gets generated:

$ nm -D /usr/bin/angelfish-webapp | grep Qt_5_PRIVATE_API
                 U _ZN22QQuickWebEngineProfile16downloadFinishedEP27QQuickWebEngineDownloadItem@Qt_5_PRIVATE_API
                 U _ZN22QQuickWebEngineProfile17downloadRequestedEP27QQuickWebEngineDownloadItem@Qt_5_PRIVATE_API
$

You are jumping to conclusions too fast without double-checking things,
which is not a good sign for someone who wants to provide security support
for what is perhaps the most difficult to support package in Debian.

That's also true for the whole effort:

Everyone who has looked at this before came to the conclusion that
security support for browser engines is no longer possible on a
volunteer basis in Debian since it is:
- a lot of work for many CVEs, and
- requires deep technical skills of the browser engine
  (How much experience do you have modifying the Blink code?), and
- backporting fixes to ancient versions of software is sometimes easy
  but sometimes the kind of nasty work most people won't do unpaid

It is not fundamentally impossible, but it's in the order of magnitude
of one full-time employed Blink engineer.

bookworm-backports are packages from trixie rebuilt for bookworm.

Whatever you want to do in backports, it has to go into unstable und
migrate to testing first.

cu
Adrian

Adrian,

The public version of this class is found in:

qquickwebengineprofile.h

Which is part of the qtwebengine5-dev package.

Private versions of this class can be found in:

qquickwebengineprofile_p.h
qquickwebenginedownloaditem_p.h

which are part of the qtwebengine5-private-dev package.

This does beg the question of how angelfish builds against this private header
without build-depending on qtwebengine5-private-dev.  Perhaps that is an
answer that one of the angelfish maintainers, Pirate or Nilesh, can answer.

But as I mentioned in a previous email, it boggles the imagination that a
security patch would ever modify the download notification API (or anything in
the very high-level, non Chromium or Blink rendering engine headers in the
qtwebengine-private-dev package).  So, this isn’t likely to impact efforts to
maintain security updates in stable.

That is exactly what I am planning to do.  I am going to backport qtwebengine-
opensource-src 5.15.15+dfsg-2, which is currently in trixie, to bookworm.
When 5.15.16 lands in trixie, I will backport that to bookworm.

This provides a way for those on stable who would like Qt WebEngine security
updates to install them, while also making it easy to revert to the version in
stable if the updates cause problems.

Hi Soren!

I uploaded 5.15.13+dfsg-1 to experimental on 2023-03-19, when we were already
a week into hard freeze, and I was not sure if the release team would approve
an upload to unstable.

They approved, but requested me to drop the pipewire enablement change
(see #1032794), so I uploaded to unstable with a lower version number.

QQuickWebEngineProfile is public. However, QQuickWebEngineDownloadItem, which
is the argument of downloadFinished() and downloadRequested(), is private.
In Qt 6 this class is renamed to QQuickWebEngineDownloadRequest, but it is
still private for some reason.

Angelfish includes the private header when building against Qt 6, and uses a
stub header for Qt 5, as can be seen from the following code:

  #if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
  #include "qquickwebenginedownloaditem.h"
  using DownloadItem = QQuickWebEngineDownloadItem;
  #else
  #include <private/qquickwebenginedownloadrequest_p.h>
  using DownloadItem = QQuickWebEngineDownloadRequest;
  #endif

Using a stub header results in dependency on private ABI just like including
a normal header.

I think that angelfish developers should ask Qt upstream to make that class
public, explaining how and why they use it.

I wonder if that just happens for the QML version of WebEngineDownloadItem.

https://doc.qt.io/qt-5/qml-qtwebengine-webenginedownloaditem.html[1]

It doesn’t affect Privacy Browser, but I use the C++ version of WebEngineDownloadItem.

https://doc.qt.io/qt-5/qwebenginedownloaditem.html[2]

$ nm -D /usr/bin/privacybrowser | grep Qt_5_PRIVATE_API
$

That makes sense to me.  I have filed a Debian bug and an upstream bug against Angelfish.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059164[3]

https://bugs.kde.org/show_bug.cgi?id=478783[4]

--------
[1] https://doc.qt.io/qt-5/qml-qtwebengine-webenginedownloaditem.html
[2] https://doc.qt.io/qt-5/qwebenginedownloaditem.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059164
[4] https://bugs.kde.org/show_bug.cgi?id=478783

Hi Soren!

Yes, it affects only the Qt Quick version. The C++ version is public:

$ dpkg -L qtwebengine5-dev | grep -i downloaditem
/usr/include/x86_64-linux-gnu/qt5/QtWebEngineWidgets/QWebEngineDownloadItem
/usr/include/x86_64-linux-gnu/qt5/QtWebEngineWidgets/qwebenginedownloaditem.h

$ dpkg -L qtwebengine5-private-dev | grep -i downloaditem
/usr/include/x86_64-linux-gnu/qt5/QtWebEngine/5.15.15/QtWebEngine/private/qquickwebenginedownloaditem_p.h
/usr/include/x86_64-linux-gnu/qt5/QtWebEngine/5.15.15/QtWebEngine/private/qquickwebenginedownloaditem_p_p.h
/usr/include/x86_64-linux-gnu/qt5/QtWebEngineWidgets/5.15.15/QtWebEngineWidgets/private/qwebenginedownloaditem_p.h

Small correction for your bug report. You write:

“Qt 6 has a public version of this API:
https://doc.qt.io/qt-6/qml-qtwebengine-webenginedownloadrequest.html”

However, that link is for the QML interface documentation. But what angelfish
actually does is using the Qt Quick class from the C++ code. As I understand,
you have to do such things when you have mixed QML and C++ code, and want to
interact with QML components from the C++ part.

Dmitry,

I must admit that I have no personal experience with connecting QML and C++.  But it
seems to me from the documentation Qt has produced there are several ways to bridge the
two without accessing private headers.

https://doc.qt.io/qt-5/qtqml-cppintegration-overview.html[1]

Beyond what is written there, Angelfish deals with a lot of classes besides
WebEngineDownloadItem.  Somehow, with all the others, they are able to do what they
need to do without accessing private headers, which would indicate to me that there must
be some way to do it in this case as well.

--------
[1] https://doc.qt.io/qt-5/qtqml-cppintegration-overview.html

I don’t have any personal experience with that too.

I didn’t say that you need private headers for _any_ stuff like that.

Just one particular class (QQuickWebEngineDownloadItem) is private. My guess
is that it’s upstream oversight, because upstream documentation even mentions
that one needs to call QWebEngineDownloadRequest::accept() [1], yet calling
that method is not possible without including a private header.

[1]: https://doc.qt.io/qt-6/qquickwebengineprofile.html#downloadRequested

mentions

There is both a public and a private version of the header for this class,
similar to a lot of classes in Qt WebEngine.

The public versions of this header are contained in `qquickwebengineprofile.h`
and `qwebenginedownloadrequest.h` in the qt6-webengine-dev package.

The private versions of this header are contained in
`qquickwebengineprofile_p.h` and `qquickwebenginedownloadrequest_p.h` in the
qt6-webengine-private-dev package.


On the C++ side, the public versions of these headers are contained in
`qwebengineprofile.h` and `qwebenginedownloadrequest.h` (note how both versions
end up depending on the same `qwebenginedownloadrequest.h` where all of the
real logic resides) in the qt6-webengine-dev package.

The private version of the C++ header are contained in `qwebengineprofile_p.h`
and `qwebenginedownloadrequest_p.h` contained in the qt6-webengine-private-dev
package.


It isn’t clear to me why Qt feels the need to have private headers that mirror
their public headers for many of their functions.  And there may be some way
in which Qt borked their public QML implementation of this particular class in
such a way that one really does need to depend on the private headers (in
which case, as Dmitry has pointed out, they would probably be very willing to
fix it if it was reported to them).  But from what I can see by reviewing the
code (without taking the time to actually build a project and test it out
myself) it ought to be possible for Angelfish to just switch to using the
public headers.

Hi Soren,

QQuickWebEngineProfile ≠ QQuickWebEngineDownloadRequest
QWebEngineDownloadRequest ≠ QQuickWebEngineDownloadRequest

Maybe my previous emails were not clear enough, let me try again.

Qt has two different interface systems: Qt Widgets and Qt Quick.

Qt Widgets can be used from C++ only. Qt Quick is intended for use from QML,
but sometimes it can be controlled from C++ code, that's why there are C++
classes for it too.

Many Qt modules, including Qt WebEngine, provide classes for both interface
systems.

For example, qt6-webengine source in Debian builds libqt6webenginewidgets6 and
libqt6webenginequick6 binary packages.

Angelfish is written in Qt Quick, unlike many other browsers which are using
Qt Widgets. This is why it needs QQuick* classes, and the widgets classes
can not be a replacement.

This way you can easily change private ABI (e.g. add a new argument) without
breaking the public interface.

See https://wiki.qt.io/D-Pointer for details.

Probably. Feel free to create an upstream bug report, based on the analysis
from my previous email.

As explained above, no, QQuickWebEngineDownloadRequest does not have a public
header.

I created an upstream Qt bug report.

https://bugreports.qt.io/browse/QTBUG-120370[1]

--------
[1] https://bugreports.qt.io/browse/QTBUG-120370

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

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 <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
<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:

https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?h=87-based&id=ce00f9b5aa761866b24d6460e10aacb671c92cf0
<https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?h=87-based&id=ce00f9b5aa761866b24d6460e10aacb671c92cf0>

https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?h=87-based&id=b970585ffa5e657364d6f249461dc613c5e53958
<https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?h=87-based&id=b970585ffa5e657364d6f249461dc613c5e53958>

https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?h=87-based&id=207c2ac45ca3386d153770c6b0d2ea2ec21ca880
<https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?h=87-based&id=207c2ac45ca3386d153770c6b0d2ea2ec21ca880>

Every once in a while, a commit is much more invasive:

https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?h=87-based&id=6b9b349abaa2bb8b60821a1daf02cce536fac809
<https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?h=87-based&id=6b9b349abaa2bb8b60821a1daf02cce536fac809>

When Qt WebEngine from 6.5 is officially backportable to 6.2,
then backporting it to versions between 6.2 and 6.5 is unlikely
to be a problem.

Backporting even more recent versions to 6.4 would be expected to be
easier than backporting to 6.2, since 6.4 is closer to what gets
backported and backporting problems tend to increase when the
backporting distance increases since the code differences increase.

Your "generally" is not true, it misses the biggest problem.

Out of 20 CVEs there might be 19 easy ones, plus one that is a quite
invasive patch requiring a lot of backporting work.

Who has both the required skills and a reliable commitment today for
doing in the year 2027 an urgent backport of a complex fix for a
zero-day vulnerability that is already being exploited in the wild?

cu
Adrian

lines.

I intend to be involved in this work for a lot longer than 2027, although
there will probably come a point 30 or 40 years down the road when I will need
to hand it off to a future generation.

As for the necessary skills, that is something I expect to pick up through a
combination of hard work and being willing to ask questions.

qtwebengine-opensource-src 5.15.15+dfsg-2~bpo12+2 (a recent version of Qt
WebEngine 5) is now available in bookworm-backports.  I intend to backport
5.15.16 when it lands in testing.  You are welcome to try our the packages and
see if you encounter any bugs.

https://tracker.debian.org/pkg/qtwebengine-opensource-src