Bug#1057755: Qt WebEngine Security Support In Stable

[Soren Stoutner <soren@stoutner.com>]

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.

--
Soren Stoutner
623-262-6169
soren@stoutner.com