Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1177712 > unrolled thread

Bug#1057755: qt6-webengine: Support security updates in stable

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1057755: qt6-webengine: Support security updates in stable Soren Stoutner <soren@stoutner.com> - 2023-12-08 02:40 +0100
    Bug#1057755: Qt WebEngine Security Support In Stable Patrick Franz <deltaone@debian.org> - 2023-12-13 21:20 +0100
      Re: Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-13 22:20 +0100
        Bug#1057755: Qt WebEngine Security Support In Stable Patrick Franz <deltaone@debian.org> - 2023-12-13 23:10 +0100
          Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-14 00:50 +0100
            Bug#1057755: Qt WebEngine Security Support In Stable Mike Gabriel <sunweaver@debian.org> - 2023-12-14 09:10 +0100
        Re: Bug#1057755: Qt WebEngine Security Support In Stable Adrian Bunk <bunk@debian.org> - 2023-12-14 02:40 +0100
          Re: Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-14 05:00 +0100
            Re: Bug#1057755: Qt WebEngine Security Support In Stable Paul Gevers <elbrus@debian.org> - 2023-12-14 08:40 +0100
              Re: Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-14 08:50 +0100
                Re: Bug#1057755: Qt WebEngine Security Support In Stable Paul Gevers <elbrus@debian.org> - 2023-12-14 09:10 +0100
                  Re: Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-14 21:00 +0100
            Re: Bug#1057755: Qt WebEngine Security Support In Stable Adrian Bunk <bunk@debian.org> - 2023-12-14 13:40 +0100
            Bug#1057755: Qt WebEngine Security Support In Stable Alberto Garcia <berto@igalia.com> - 2023-12-15 02:30 +0100
              Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-16 21:30 +0100
                Bug#1057755: Qt WebEngine Security Support In Stable Adrian Bunk <bunk@debian.org> - 2023-12-17 00:20 +0100
                  Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-17 00:40 +0100
                    Bug#1057755: Qt WebEngine Security Support In Stable Patrick Franz <deltaone@debian.org> - 2023-12-17 01:00 +0100
                      Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-17 01:30 +0100
                        Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-17 02:10 +0100
                          Bug#1057755: Qt WebEngine Security Support In Stable Adrian Bunk <bunk@debian.org> - 2023-12-17 11:20 +0100
                            Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-18 18:40 +0100
                              Bug#1057755: Qt WebEngine Security Support In Stable Dmitry Shachnev <mitya57@debian.org> - 2023-12-20 15:10 +0100
                                Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-20 20:30 +0100
                                  Bug#1057755: Qt WebEngine Security Support In Stable Dmitry Shachnev <mitya57@debian.org> - 2023-12-20 21:30 +0100
                                    Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-20 22:10 +0100
                                      Bug#1057755: Qt WebEngine Security Support In Stable Dmitry Shachnev <mitya57@debian.org> - 2023-12-21 11:10 +0100
                                        Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-21 21:00 +0100
                                          Bug#1057755: Qt WebEngine Security Support In Stable Dmitry Shachnev <mitya57@debian.org> - 2023-12-21 22:00 +0100
                                            Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-22 23:00 +0100
                                              Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2024-01-09 02:50 +0100
                    Bug#1057755: Qt WebEngine Security Support In Stable Dmitry Shachnev <mitya57@debian.org> - 2023-12-20 14:40 +0100
    Bug#1057755: Qt WebEngine Security Support In Stable Adrian Bunk <bunk@debian.org> - 2023-12-15 00:30 +0100
    Bug#1057755: Qt WebEngine Security Support In Stable Adrian Bunk <bunk@debian.org> - 2023-12-15 09:50 +0100
      Bug#1057755: Qt WebEngine Security Support In Stable Moritz Muehlenhoff <jmm@inutil.org> - 2023-12-15 20:30 +0100
    Bug#1057755: Qt WebEngine Security Support In Stable Ratchanan Srirattanamet <ratchanan@ubports.com> - 2023-12-23 15:10 +0100
    Bug#1057755: Qt WebEngine Security Support In Stable Adrian Bunk <bunk@debian.org> - 2023-12-24 12:00 +0100
      Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-26 20:00 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1179038 — Bug#1057755: Qt WebEngine Security Support In Stable

On Sat, Dec 16, 2023 at 04:33:58PM -0700, Soren Stoutner wrote:
> On Saturday, December 16, 2023 4:10:42 PM MST Adrian Bunk wrote:
> > On Sat, Dec 16, 2023 at 01:22:13PM -0700, Soren Stoutner wrote:
> > > Bookworm released with qtwebengine-opensource-src 5.15.8+dfsg-1, but
> > > 5.15.13+dfsg-1~deb12u1 was later uploaded.
> >
> > That's not true, bookworm released with 5.15.13+dfsg-1~deb12u1.
>
> How does stable initially release with an ~deb12u1?

On Sat, Dec 16, 2023 at 06:00:28PM -0700, Soren Stoutner wrote:
> 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).

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.

>...
> 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?
>...

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

[toc] | [prev] | [next] | [standalone]

#1179190 — Bug#1057755: Qt WebEngine Security Support In Stable

[Multipart message — attachments visible in raw view] — view raw

Adrian,

On Sunday, December 17, 2023 3:11:10 AM MST Adrian Bunk wrote:
> 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
> _ZN22QQuickWebEngineProfile16downloadFinishedEP27QQuickWebEngineDownloadIte
> m@Qt_5_PRIVATE_API U
> _ZN22QQuickWebEngineProfile17downloadRequestedEP27QQuickWebEngineDownloadIt
> em@Qt_5_PRIVATE_API $

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.

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

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.

-- 
Soren Stoutner
soren@stoutner.com

[toc] | [prev] | [next] | [standalone]

#1179506 — Bug#1057755: Qt WebEngine Security Support In Stable

[Multipart message — attachments visible in raw view] — view raw

On Mon, Dec 18, 2023 at 10:34:17AM -0700, Soren Stoutner wrote:
> Adrian,
> 
> On Sunday, December 17, 2023 3:11:10 AM MST Adrian Bunk wrote:
> > 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
> > _ZN22QQuickWebEngineProfile16downloadFinishedEP27QQuickWebEngineDownloadIte
> > m@Qt_5_PRIVATE_API U
> > _ZN22QQuickWebEngineProfile17downloadRequestedEP27QQuickWebEngineDownloadIt
> > em@Qt_5_PRIVATE_API $
> 
> 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.

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.

--
Dmitry Shachnev

[toc] | [prev] | [next] | [standalone]

#1179545 — Bug#1057755: Qt WebEngine Security Support In Stable

[Multipart message — attachments visible in raw view] — view raw

On Wednesday, December 20, 2023 7:01:47 AM MST Dmitry Shachnev wrote:
> Using a stub header results in dependency on private ABI just like including
> a normal header.

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
$ 
 
> I think that angelfish developers should ask Qt upstream to make that class
> public, explaining how and why they use it.

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]

-- 
Soren Stoutner
soren@stoutner.com

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

[toc] | [prev] | [next] | [standalone]

#1179551 — Bug#1057755: Qt WebEngine Security Support In Stable

[Multipart message — attachments visible in raw view] — view raw

Hi Soren!

On Wed, Dec 20, 2023 at 12:23:15PM -0700, Soren Stoutner wrote:
> On Wednesday, December 20, 2023 7:01:47 AM MST Dmitry Shachnev wrote:
> > Using a stub header results in dependency on private ABI just like including
> > a normal header.
> 
> I wonder if that just happens for the QML version of WebEngineDownloadItem.
> 
> https://doc.qt.io/qt-5/qml-qtwebengine-webenginedownloaditem.html
> 
> It doesn’t affect Privacy Browser, but I use the C++ version of WebEngineDownloadItem.
> 
> https://doc.qt.io/qt-5/qwebenginedownloaditem.html
> 
> $ nm -D /usr/bin/privacybrowser | grep Qt_5_PRIVATE_API
> $ 

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
 
> > I think that angelfish developers should ask Qt upstream to make that class
> > public, explaining how and why they use it.
> 
> 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
> 
> https://bugs.kde.org/show_bug.cgi?id=478783

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 Shachnev

[toc] | [prev] | [next] | [standalone]

#1179553 — Bug#1057755: Qt WebEngine Security Support In Stable

[Multipart message — attachments visible in raw view] — view raw

Dmitry,

On Wednesday, December 20, 2023 1:21:49 PM MST Dmitry Shachnev wrote:
> 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.

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.

-- 
Soren Stoutner
soren@stoutner.com

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

[toc] | [prev] | [next] | [standalone]

#1179629 — Bug#1057755: Qt WebEngine Security Support In Stable

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 20, 2023 at 02:06:28PM -0700, Soren Stoutner wrote:
> I must admit that I have no personal experience with connecting QML and C++.

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

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

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

--
Dmitry Shachnev

[toc] | [prev] | [next] | [standalone]

#1179684 — Bug#1057755: Qt WebEngine Security Support In Stable

[Multipart message — attachments visible in raw view] — view raw

On Thursday, December 21, 2023 3:00:23 AM MST Dmitry Shachnev wrote:
> 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

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.

-- 
Soren Stoutner
soren@stoutner.com

[toc] | [prev] | [next] | [standalone]

#1179692 — Bug#1057755: Qt WebEngine Security Support In Stable

[Multipart message — attachments visible in raw view] — view raw

Hi Soren,

On Thu, Dec 21, 2023 at 12:48:44PM -0700, Soren Stoutner wrote:
> On Thursday, December 21, 2023 3:00:23 AM MST Dmitry Shachnev wrote:
> > 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
> 
> 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.

No, they are both not of _this_ header.

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.

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

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.

> 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).

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

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

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

--
Dmitry Shachnev

[toc] | [prev] | [next] | [standalone]

#1179864 — Bug#1057755: Qt WebEngine Security Support In Stable

[Multipart message — attachments visible in raw view] — view raw

On Thursday, December 21, 2023 1:48:02 PM MST Dmitry Shachnev wrote:
> > 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).
> 
> Probably. Feel free to create an upstream bug report, based on the analysis
> from my previous email.

I created an upstream Qt bug report.

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

-- 
Soren Stoutner
soren@stoutner.com

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

[toc] | [prev] | [next] | [standalone]

#1181664 — Bug#1057755: Qt WebEngine Security Support In Stable

[Multipart message — attachments visible in raw view] — view raw

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

-- 
Soren Stoutner
soren@stoutner.com

[toc] | [prev] | [next] | [standalone]

#1179504 — Bug#1057755: Qt WebEngine Security Support In Stable

[Multipart message — attachments visible in raw view] — view raw

Hi Soren!

On Sat, Dec 16, 2023 at 04:33:58PM -0700, Soren Stoutner wrote:
> On Saturday, December 16, 2023 4:10:42 PM MST Adrian Bunk wrote:
> > On Sat, Dec 16, 2023 at 01:22:13PM -0700, Soren Stoutner wrote:
> > > Bookworm released with qtwebengine-opensource-src 5.15.8+dfsg-1, but
> > > 5.15.13+dfsg-1~deb12u1 was later uploaded.
> >
> > That's not true, bookworm released with 5.15.13+dfsg-1~deb12u1.
>
> How does stable initially release with an ~deb12u1?

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.

--
Dmitry Shachnev

[toc] | [prev] | [next] | [standalone]

#1178752 — Bug#1057755: Qt WebEngine Security Support In Stable

On Thu, Dec 14, 2023 at 12:48:08PM -0700, Soren Stoutner wrote:
>...
> This plan does not address oldstable security support.
>...

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.

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

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

> Soren Stoutner

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#1178786 — Bug#1057755: Qt WebEngine Security Support In Stable

On Thu, Dec 14, 2023 at 05:29:43PM -0700, Soren Stoutner wrote:
> 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.

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.

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

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.

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

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.

> Particularly if there was assistance by a team of interested people.

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.

> Soren Stoutner

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#1178850 — Bug#1057755: Qt WebEngine Security Support In Stable

On Fri, Dec 15, 2023 at 10:39:04AM +0200, Adrian Bunk wrote:
> > 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.
> 
> >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.

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

[toc] | [prev] | [next] | [standalone]

#1179906 — Bug#1057755: Qt WebEngine Security Support In Stable

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

[toc] | [prev] | [next] | [standalone]

#1179978 — Bug#1057755: Qt WebEngine Security Support In Stable

On Sat, Dec 23, 2023 at 03:55:15PM -0700, Soren Stoutner wrote:
>...
> 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 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.

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

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?

> Soren Stoutner

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#1180157 — Bug#1057755: Qt WebEngine Security Support In Stable

[Multipart message — attachments visible in raw view] — view raw

On Sunday, December 24, 2023 3:50:26 AM MST Adrian Bunk wrote:
> > 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:
> >...
> 
> 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?

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.

-- 
Soren Stoutner
soren@stoutner.com

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.bugs.dist

csiph-web