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.
> 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. The latest LTS point release of Qt WebEngine 5.15.16 was comprised of 11 commits.
https://code.qt.io/cgit/qt/qtwebengine.git/log/?h=5.15.16
Some of them don’t have any security implications. The following commits do (some with CVEs and others without).
In addition, this commit checks for an important potential compatibility issue with recent versions of FFMpeg:
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. For example, libtiff:
https://bugs.chromium.org/p/chromium/issues/detail?id=1399080
libwebp:
I have been working recently in getting Qt WebEngine to build using system copies of libraries instead of the bundled versions. This often involves coordinating efforts with upstream Qt and Google. For example, in the case of libtiff, Chromium was using a private header, which made building against the system library unfeasible. That problem is now fixed upstream.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033747
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033749
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038123
Any of these patches that fix bundled third-party libraries that we aren’t using don’t need to be backported because they will be handled by the updates that are applied by those library package maintainers.
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. Particularly if there was assistance by a team of interested people.
--
Soren Stoutner
Attachment:
OpenPGP_0x2D48F45A7EBE8C12.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature