Bug#1057755: Qt WebEngine Security Support In Stable

[Adrian Bunk <bunk@debian.org>]

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