Re: Bug#1057755: Qt WebEngine Security Support In Stable
On Sunday, December 24, 2023 3:50:26 AM MST Adrian Bunk wrote: > > If it ends up not being feasible to backport the entire Qt WebEngine from > > the next LTS release, then we could look at cherry-picking all of the > > security commits. This would be, by far, the most time-intensive solution. > > But, as your point out, the security fixes on the Chromium side are well > > marked. And, generally, they are small commits that only modify a few lines. > > > > For example: > >... > > Your "generally" is not true, it misses the biggest problem. > > Out of 20 CVEs there might be 19 easy ones, plus one that is a quite > invasive patch requiring a lot of backporting work. > > Who has both the required skills and a reliable commitment today for > doing in the year 2027 an urgent backport of a complex fix for a > zero-day vulnerability that is already being exploited in the wild? I intend to be involved in this work for a lot longer than 2027, although there will probably come a point 30 or 40 years down the road when I will need to hand it off to a future generation. As for the necessary skills, that is something I expect to pick up through a combination of hard work and being willing to ask questions. -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Re: Bug#1057755: Qt WebEngine Security Support In Stable
On Sat, Dec 23, 2023 at 03:55:15PM -0700, Soren Stoutner wrote: >... > In a hypothetical world where Qt 6.2 LTS had shipped with bookworm, we could > build any Qt WebEngine from 6.2, 6.3, or 6.4 against it without problem. > Initially it might seem best to build the highest possible, but because 6.4 > updates end a full year before 6.2 LTS updates, it would be best for stable > support if we stuck with 6.2 as long as possible. >... When Qt WebEngine from 6.5 is officially backportable to 6.2, then backporting it to versions between 6.2 and 6.5 is unlikely to be a problem. Backporting even more recent versions to 6.4 would be expected to be easier than backporting to 6.2, since 6.4 is closer to what gets backported and backporting problems tend to increase when the backporting distance increases since the code differences increase. >... > If it ends up not being feasible to backport the entire Qt WebEngine from > the next LTS release, then we could look at cherry-picking all of the > security commits. This would be, by far, the most time-intensive solution. > But, as your point out, the security fixes on the Chromium side are well > marked. And, generally, they are small commits that only modify a few lines. > For example: >... Your "generally" is not true, it misses the biggest problem. Out of 20 CVEs there might be 19 easy ones, plus one that is a quite invasive patch requiring a lot of backporting work. Who has both the required skills and a reliable commitment today for doing in the year 2027 an urgent backport of a complex fix for a zero-day vulnerability that is already being exploited in the wild? > Soren Stoutner cu Adrian
Re: Bug#1057755: Qt WebEngine Security Support In Stable
Hello, I'm Ratchanan Srirattanamet, and I'm a "maintainer" of the QtWebEngine for Ubuntu Touch (I usually pull from Debian unstable and add our patches). As such, I have a few insights and ideas regarding this. On 07-12-2023 18:49, Soren Stoutner wrote: > If this is deemed inappropriate for stable-security, it might be > possible to cherry-pick just the security updates from the Qt > WebEngine LTS releases and manually apply them to the current tarball > in stable. Is anyone familiar with how well documented Qt’s commits > are as to which are security related and which are not? At least for the Chromium side, for between a QtWebEngine patch versions (where the Chromium base has not been updated), The Qt Company tags the backported commits from Chromium with "[Backport] CVE-such-and-such" or "[Backport] Security bug ". Commits usually appear in the qtwebengine-chromium before the release time, so for certain grave issue one can cherry-pick a commit from qtwebengine-chromium side of thing and apply to Debian packaging. Obviously that depends on The Qt Company deciding to backport such commit/fix from Chromium in the first place, which might not happen in a timely manner. That said, I don't see such tagging on the Qt-side qtwebengine repository. So if a vulnerability appears on that side it could be more difficult to identify. And I still think it's better to just include the whole new version of QtWebEngine rather than cherry-picking certain patches. > > > 4. > It has been suggested that security support in stable might be > provided through stable-backports instead of stable-security. For LTS > releases this should be fairly simple (assuming the problems with > private headers described in point #1 above are resolved). For non- > LTS releases this could become overly complex because a newer version > of Qt WebEngine probably requires backporting every Qt and KDE > package, which feels unmanageable Qt actually allows building QtWebEngine with an earlier Qt versions (down to the last LTS release) [1]. We are doing this all the time; what Mike Gabriel didn't mention is we're still based on Qt 5.12.8 shipped in Ubuntu 20.04, which means we build QtWebEngine 5.15.x line against Qt 5.12.8 with no problem whatsoever (in practice we have to patch QtWebEngine a bit in the documentation building part). At one point in time, we even used to build QtWebEngine 5.14.x line against Qt 5.9.x with a relatively minor patching. So, there's really no need to backport the rest of Qt and KDE stack in order to provide a more up-to-date QtWebEngine (or stick with LTS Qt in stable), except for maybe QtWebView and Angelfish. If you're willing to do a bit mind-bending, it might even be possible to stay with the LTS release of QtWebEngine while upgrading the rest of the Qt stack up. Can't say if that is desirable though. :D [1]: https://doc.qt.io/qt-5/qtwebengine-platform-notes.html#using-earlier-qt-versions-to-build-qt-webengine --- Ratchanan Srirattanamet
Re: Bug#1057755: Qt WebEngine Security Support In Stable
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 signature.asc Description: PGP signature
Re: Bug#1057755: Qt WebEngine Security Support In Stable
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 signature.asc Description: PGP signature
Re: Bug#1057755: Qt WebEngine Security Support In Stable
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 signature.asc Description: PGP signature
Re: Bug#1057755: Qt WebEngine Security Support In Stable
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 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 signature.asc Description: PGP signature
Re: Bug#1057755: Qt WebEngine Security Support In Stable
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 signature.asc Description: PGP signature
Re: Bug#1057755: Qt WebEngine Security Support In Stable
On Sat, Dec 16, 2023 at 04:33:58PM -0700, Soren Stoutner wrote: > On Saturday, December 16, 2023 4:10:42 PM MST Adrian Bunk wrote: > > On Sat, Dec 16, 2023 at 01:22:13PM -0700, Soren Stoutner wrote: > > > Bookworm released with qtwebengine-opensource-src 5.15.8+dfsg-1, but > > > 5.15.13+dfsg-1~deb12u1 was later uploaded. > > > > That's not true, bookworm released with 5.15.13+dfsg-1~deb12u1. > > How does stable initially release with an ~deb12u1? On Sat, Dec 16, 2023 at 06:00:28PM -0700, Soren Stoutner wrote: > Digging into this a little further, it looks like the current version of > Angelfish does not use > any Qt WebEngine private headers (qtwebengine5-private-dev is not listed as a > build- > depends). I don't know what's going on with the headers, but there is a reason why the dependency gets generated: $ nm -D /usr/bin/angelfish-webapp | grep Qt_5_PRIVATE_API U _ZN22QQuickWebEngineProfile16downloadFinishedEP27QQuickWebEngineDownloadItem@Qt_5_PRIVATE_API U _ZN22QQuickWebEngineProfile17downloadRequestedEP27QQuickWebEngineDownloadItem@Qt_5_PRIVATE_API $ You are jumping to conclusions too fast without double-checking things, which is not a good sign for someone who wants to provide security support for what is perhaps the most difficult to support package in Debian. That's also true for the whole effort: Everyone who has looked at this before came to the conclusion that security support for browser engines is no longer possible on a volunteer basis in Debian since it is: - a lot of work for many CVEs, and - requires deep technical skills of the browser engine (How much experience do you have modifying the Blink code?), and - backporting fixes to ancient versions of software is sometimes easy but sometimes the kind of nasty work most people won't do unpaid It is not fundamentally impossible, but it's in the order of magnitude of one full-time employed Blink engineer. >... > Now that is all cleared up, I think that next week I am going to build the > current version > of Qt 5 WebEngine for stable and test it on a system I have running locally, > focusing > specifically on all of the browsers that use Qt WebEngine. If all seems to > work well, would > anyone have any objections to me uploading it to bookworm-backports? >... bookworm-backports are packages from trixie rebuilt for bookworm. Whatever you want to do in backports, it has to go into unstable und migrate to testing first. cu Adrian
Re: 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
Re: 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
Re: Bug#1057755: Qt WebEngine Security Support In Stable
On Fri, Dec 15, 2023 at 10:39:04AM +0200, Adrian Bunk wrote: > > That is a good point. However, I consider full coverage of security support > > for stable to be an improvement over the current situation. Explicitly > > stating that security support is not shipped for oldstable does not do any > > more harm to users than what we currently do by explicitly stating that > > security support is not shipped for either stable or oldstable. > > >From a policy point of view, the duration of security support is a > Debian-wide policy and not a per-package policy. > > >From a user point of view, an organization/company running Debian on > their user/employee desktops would not schedule upgrades to a new > stable on release day - 1 year of migration time is really necessary. We already set some tighter deadlines, Chromium security support will also end six months after the release of the next stable release. But I agree with the general sentiment that this too much work to directly commit to full security support. A first step would be to initially commit to rebase to the latest LTS release in every point release. That would already be an improvement. Cheers, Moritz
Re: Bug#1057755: Qt WebEngine Security Support In Stable
On Thu, Dec 14, 2023 at 05:29:43PM -0700, Soren Stoutner wrote: > On Thursday, December 14, 2023 4:19:17 PM MST Adrian Bunk wrote: > > > Non-LTS oldstable is the 3rd year of stable security support, > > this is required for giving users time to schedule the invasive > > upgrades to a new Debian stable at a convenient time. > > > > LTS oldstable (after regular security support has ended) is a paid > > endeavour outside the scope of what Debian volunteers are expected > > to support. > > That is a good point. However, I consider full coverage of security support > for stable to be an improvement over the current situation. Explicitly > stating that security support is not shipped for oldstable does not do any > more harm to users than what we currently do by explicitly stating that > security support is not shipped for either stable or oldstable. >From a policy point of view, the duration of security support is a Debian-wide policy and not a per-package policy. >From a user point of view, an organization/company running Debian on their user/employee desktops would not schedule upgrades to a new stable on release day - 1 year of migration time is really necessary. >From a security point of view, providing updates would be an improvement. E.g. upgrading Qt5 WebEngine in bullseye and bookworm to 5.15.15 in point releases might already be an option. But that's different from calling something security supported, which could do more harm than good by giving users a false sense of security instead of looking for alternatives. > > By calling this "doable" you are demonstrating that you do not fully > > grasp why browser engines are considered unsupportable. > > > > In recent years, chromium had on average more than 1 CVE per day: > > https://security-tracker.debian.org/tracker/source-package/chromium > > That is true. However, not all of those bugs apply to Qt WebEngine. >... > A number of these patches would apply to an older LTS without modification. > Some would need minor modifications. Some would not apply to an older LTS > because they are fixing problems in features that were released after the > LTS. And some would require significant effort to backport. > > Additionally, a number of recent high-profile Chromium vulnerabilities have > been in third-party libraries and not in Chromium itself. >... Part of the problem is that "some would require significant effort" might end up meaning that 5% of the CVEs take 95% of the time. There might be a 0-day vulnerability that is already being exploited by nation-state actors where they had to rewrite half the browser to fix it. >... > Considering all of the above, handling security support in stable would > obviously be a lot of work, but to me it feels like it is in the realm of > what is doable. Providing security support by backporting fixes to Qt WebEngine feels to me more like in the realm of one full-time employed Blink engineer. It would be both a lot of work and requires relevant skills from the people doing it. > Particularly if there was assistance by a team of interested people. For trixie, you would need people who reliably commit in 2024 to doing a lot of work in 2026-2028. Even your "no support for oldstable" would keep you busy in the first half of 2027. What is your track record in Debian of still being active several years later? You are also vastly overestimating the number of people available for such work in Debian. Debian has few very active people, sometimes literally (co)maintaining > 1000 packages, but most people are only maintaining one or few packages. Qt6 has ~ 2 active maintainers, and many key areas/packages of Debian have a single person. Realistically, your effort would be a team with one member. > Soren Stoutner cu Adrian
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. 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
Re: Bug#1057755: Qt WebEngine Security Support In Stable
On Thu, Dec 14, 2023 at 12:48:08PM -0700, Soren Stoutner wrote: >... > This plan does not address oldstable security support. >... Non-LTS oldstable is the 3rd year of stable security support, this is required for giving users time to schedule the invasive upgrades to a new Debian stable at a convenient time. LTS oldstable (after regular security support has ended) is a paid endeavour outside the scope of what Debian volunteers are expected to support. >... > 3. When the LTS in stable is no longer supported, security patches can be > backported from the current LTS to the one in stable. > > This sounds like a doable amount of security work and I would be willing to > undertake it. >... By calling this "doable" you are demonstrating that you do not fully grasp why browser engines are considered unsupportable. In recent years, chromium had on average more than 1 CVE per day: https://security-tracker.debian.org/tracker/source-package/chromium > Soren Stoutner cu Adrian
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
Re: Bug#1057755: Qt WebEngine Security Support In Stable
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 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1057755: Qt WebEngine Security Support In Stable
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: sunwea...@debian.org, http://sunweavers.net pgp25hvYjkAmc.pgp Description: Digitale PGP-Signatur
Re: Bug#1057755: Qt WebEngine Security Support In Stable
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 OpenPGP_signature.asc Description: OpenPGP digital signature
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
