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

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 1 of 2  [1] 2  Next page →

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

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

Patrick,

On Wednesday, December 13, 2023 1:14:27 PM MST Patrick Franz wrote:
> > 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?
> 
> 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.

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.

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

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?

-- 
Soren Stoutner
soren@stoutner.com

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

[toc] | [next] | [standalone]

#121508

On Wed, Dec 13, 2023 at 02:19:04PM -0700, Soren Stoutner wrote:
>...
> 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.
>...

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.

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

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

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

#121509

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

Adrian,

On Wednesday, December 13, 2023 6:17:38 PM MST Adrian Bunk wrote:
> 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.

Qt WebEngine is a browser engine.  It is a highly modified rolling fork of 
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.

-- 
Soren Stoutner
soren@stoutner.com

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

#121510

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

Hi Soren,

On 14-12-2023 04:49, Soren Stoutner wrote:
> Currently there is no real security support for Qt WebEngine in stable, which
> is an oversight that might surprise many Debian users.

It's explicitly documented in the release notes: 
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

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

#121511

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

Paul,

On Thursday, December 14, 2023 12:37:51 AM MST Paul Gevers wrote:
> Hi Soren,
> 
> On 14-12-2023 04:49, Soren Stoutner wrote:
> 
> > Currently there is no real security support for Qt WebEngine in stable,
> > which is an oversight that might surprise many Debian users.
> 
> It's explicitly documented in the release notes: 
> https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.
> en.html#limited-security-support  so I wouldn't call it an oversight.

Point taken.

How do you recommend we change that?

--
Soren Stoutner
soren@stoutner.com

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

#121512

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

Hi Soren,

On 14-12-2023 08:45, Soren Stoutner wrote:
> How do you recommend we change that?

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

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

#121518

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

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.

On Thursday, December 14, 2023 1:06:06 AM MST Paul Gevers wrote:
> 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-ver
> sions.md

-- 
Soren Stoutner
soren@stoutner.com

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

#121515

On Wed, Dec 13, 2023 at 08:49:55PM -0700, Soren Stoutner wrote:
>...
> 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.

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.

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

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

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

#121520

On Wed, Dec 13, 2023 at 08:49:55PM -0700, Soren Stoutner wrote:
> 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.

Hello,

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

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

#121532

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

Alberto

On Thursday, December 14, 2023 6:23:57 PM MST Alberto Garcia wrote:
> I would like to offer my (outsider) perspective as the Debian
> WebKitGTK / WPE WebKit maintainer.

Thanks for that perspective.  It is very informative.

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

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.

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

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

-- 
Soren Stoutner
soren@stoutner.com

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

#121542

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.

> At this point, the biggest remaining question is what is the private header 
> that angelfish is using in Qt WebEngine and why?
>...

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

> Thanks,
> 
> Soren

cu
Adrian

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

#121543

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

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?

> > At this point, the biggest remaining question is what is the private
> > header
> > that angelfish is using in Qt WebEngine and why?
> >
> >...
> 
> No matter what angelfish does, qtwebview-opensource-src will in any case
> also need a rebuild.

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.

-- 
Soren Stoutner
soren@stoutner.com

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

#121544

Hej,

Am Sonntag, 17. Dezember 2023, 00:33:58 CET schrieb Soren Stoutner:
[...]
> > No matter what angelfish does, qtwebview-opensource-src will in any
> > case also need a rebuild.
> 
> 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.

There is one: https://tracker.debian.org/pkg/qt6-webview

Are you perhaps confusing Qt WebView with Qt WebKit ?


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

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


-- 
Med vänliga hälsningar

Patrick Franz

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

#121545

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

On Saturday, December 16, 2023 4:53:48 PM MST Patrick Franz wrote: 
> > 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.
> 
> There is one: https://tracker.debian.org/pkg/qt6-webview
> 
> Are you perhaps confusing Qt WebView with Qt WebKit ?

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.

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

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.

-- 
Soren Stoutner
soren@stoutner.com

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

#121546

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

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?

On Saturday, December 16, 2023 5:16:58 PM MST Soren Stoutner wrote:
> 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.


-- 
Soren Stoutner
soren@stoutner.com

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

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

#121548

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]

#121568

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

#121647

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

#121649

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

#121650

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web