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
