Re: security support in buster and the release notes
> I am reaching out to you to align on the security support that users can
> expect during the lifetime of buster and how this is covered in the
> release notes.
> The release notes currently contain a section on "Limitations in
> security support", which currently covers:
> * web browsers and their rendering engines
> * ecosystem around libv8 and Node.js
> Do these subjects still cover your current view of the support for
> buster. Especially about the second item I am not sure if it still
> applies (although I expect so).
webkit2gtk will be covered by security support in buster, this has been
sorted out with the maintainers (and primarily with Alberto), it has
worked fine for Ubuntu since their last release and I'm optimistic
it will also work out fine for Buster.
The various webkit forks in QT are still not sanely supportable,
but noone else including upstream really covers them with security
support, so I think these are fine to be simply listed in
src:debian-security-support, I'm not sure really warrant a further
callout in the release notes. Same for whatever version of mozjs
we'll ship in buster.
For Nodejs, upstream has fixed their processes and there are now
sensible long term branches which are updated in a professional manner,
so nodejs (and transitively the node-* packages) are properly supportable
(and we've also sorted out with Jememy and Xavier that they agree that
it's supportable). Further work needs to happen to trim down the
set of packages (there's a number of "upload once because I need this
as a build dep" kind of dead packages), but that can be dealt with after
the buster release.
libv8 in the form of src:libv8-3.14) is still a mess and won't be
part of buster anyway (maybe it can be built out of the libv8 copy
shipped by nodejs for bullseye).
I'll update debian-security-support in the next days to reflect all
> Are there other concerns or warnings and
> should they already be mentioned in the release notes?
There has been no visible movement on the issues with Go as mentioned in
this dates back much further, initial discussions were from 2016 or
This is already an issue in Stretch (e.g. #922170), but will be much
worse in Buster, so unless someone reliably commits to work on
this ASAP the available options are to drop everything Go apart
from the toolchain packages from buster or exclude of all that mess
from security updates so that people know what they can expect.
> On top of the above questions, of course it would be great if you would
> check the wording of the current text .
Ack, I'll have a look in the next days.