Bug#971515: Request for security team input on kubernetes TC bug

[Moritz Mühlenhoff <jmm@inutil.org>]

On Sun, Nov 08, 2020 at 10:49:31PM +0100, Florian Weimer wrote:
> * Moritz Mühlenhoff:
> 
> > * Follow a scheme similar to Firefox ESR where in case of a security
> >   the update either happens to the latest minor release of
> >   the current branch or if that has stopped, happens to the next
> >   major release. To map this to specific k8s releases: Let's assume bullseye
> >   were already stable and would ship 19.3. In three months a security issue
> >   arises which is severe enough to warrant an update and we ship 19.5
> >   in a DSA. Fast forward 6 months and 19.x is EOLed, but some severe
> >   security issue needs to be fixed; then the bullseye update would move
> >   to 20.1 or so. That sounds unusual for a Debian release, but it's
> >   the status quo for _any_ Kubernetes user after all (whether deployed
> >   on premises or at some "cloud vendor").
> 
> Another thing to consider: Kubernetes rebases will likely require Go
> rebases, if I read this table correctly:
> 
> <https://github.com/kubernetes/community/blob/master/contributors/devel/development.md#go>

I can't tell how strict these requirements are in practice.

It's similar to Firefox requiring more recent versions of rustc and
golang packages are co-installable, so when it comes to that, shipping
a new golang-x.y package might also be an option.

> Since Go has a bit of spotty history in terms of kernel backwards
> compatibility, this could cause further challenges.

Do you have a concrete example of such a change? I see that 1.14 is available
in backports, so this seems to work out so far.

Cheers,
        Moritz