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

Groups > linux.debian.devel.release > #121506 > unrolled thread

Re: Bug#1057755: Qt WebEngine Security Support In Stable

Started bySoren Stoutner <soren@stoutner.com>
First post2023-12-13 22:20 +0100
Last post2023-12-20 14:40 +0100
Articles 7 on this page of 27 — 6 participants

Back to article view | Back to linux.debian.devel.release

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Bug#1057755: Qt WebEngine Security Support In Stable Soren Stoutner <soren@stoutner.com> - 2023-12-13 22:20 +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

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

#121651

FromSoren Stoutner <soren@stoutner.com>
Date2023-12-20 22:10 +0100
Message-ID<HNbZf-eWyl-1@gated-at.bofh.it>
In reply to#121650

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

#121659

FromDmitry Shachnev <mitya57@debian.org>
Date2023-12-21 11:10 +0100
Message-ID<HNoa5-f4ap-1@gated-at.bofh.it>
In reply to#121651

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

#121664

FromSoren Stoutner <soren@stoutner.com>
Date2023-12-21 21:00 +0100
Message-ID<HNxdn-f9pt-1@gated-at.bofh.it>
In reply to#121659

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

#121676

FromDmitry Shachnev <mitya57@debian.org>
Date2023-12-21 22:00 +0100
Message-ID<HNy9s-f9Zh-15@gated-at.bofh.it>
In reply to#121664

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

#121741

FromSoren Stoutner <soren@stoutner.com>
Date2023-12-22 23:00 +0100
Message-ID<HNVz3-fozG-1@gated-at.bofh.it>
In reply to#121676

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

#122008

FromSoren Stoutner <soren@stoutner.com>
Date2024-01-09 02:50 +0100
Message-ID<HU9pE-1N4J-3@gated-at.bofh.it>
In reply to#121741

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

#121646

FromDmitry Shachnev <mitya57@debian.org>
Date2023-12-20 14:40 +0100
Message-ID<HN4XM-eS0d-5@gated-at.bofh.it>
In reply to#121543

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

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

Back to top | Article view | linux.debian.devel.release

csiph-web