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

Page 1 of 2  [1] 2  Next page →

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

Source: qt6-webengine
Version: 6.4.2-final+dfsg-12
Severity: normal

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

[toc] | [next] | [standalone]

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

Hej,

Am Freitag, 8. Dezember 2023, 02:49:56 CET schrieb Soren Stoutner:
[...]
> 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.

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.


-- 
Med vänliga hälsningar

Patrick Franz

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

#1178616 — 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] | [prev] | [next] | [standalone]

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

Hej Soren,

Am Mittwoch, 13. Dezember 2023, 22:19:04 CET schrieb Soren Stoutner:
[...]
> 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.

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


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

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


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

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

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

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


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

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


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

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


-- 
Med vänliga hälsningar

Patrick Franz

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

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

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

Patrick,

On Wednesday, December 13, 2023 3:00:23 PM MST Patrick Franz wrote:
> Don't forget that the open-source Qt LTS releases are delayed by a year.

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

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

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

I didn’t know that either.

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

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

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

> > 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?
> 
> I can only do with what I have. If you want better support, you need
> more resources.

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

-- 
Soren Stoutner
soren@stoutner.com

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

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

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

Hi everyone,

On  Do 14 Dez 2023 00:38:29 CET, Soren Stoutner wrote:

> Patrick,
>
> On Wednesday, December 13, 2023 3:00:23 PM MST Patrick Franz wrote:
>> Don't forget that the open-source Qt LTS releases are delayed by a year.
>
> I wasn’t aware of that.  Can you please elaborate on how that timeline works?
> One of the things I am hoping to accomplish with this bug report is  
> to collect
> all the information that everyone has regarding this issue in one place to
> make it easy for others to find it in the future.
>
> My understanding is that LTS releases for Qt WebEngine are not  
> delayed because
> the AGPL license doesn’t allow it.

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

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

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

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

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

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

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

Off topic here. Debian can't synchronize with all upstreams the ship  
software of nor can upstreams synchronize with Debian. In theory, this  
is possible, but we in Debian should find workflows that fit with all  
upstreams. And yes, sometimes its painful missing an upstream release  
by 2 months because of Debian's freeze policy shortly before a Debian  
release.

> [...]

Responding to Qt core related thoughts only with this: Sticking with  
LTS upstreams is always a good choice for massive packaging projects  
(i.e. when many many packages are involved). This applies to Qt and  
KDE/Plasma I guess.

Greets,
Mike

-- 

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunweaver@debian.org, http://sunweavers.net

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

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

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]

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

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

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

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

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

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

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

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

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

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

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

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]

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

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]

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

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

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

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]

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

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

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

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]

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

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

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web