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
