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

[Florian Weimer]

* Moritz Mühlenhoff:

> 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:
>> 
>> 
>
> I can't tell how strict these requirements are in practice.

Let's just say that some Kubernetes developers are very eager to get
their hands on the most recent Go toolchain even if there are
practical issues with choices in the run-time library, such as the
changes to certification validation.  Not sure if anyone would want to
suffer these toolchain rebases if there was a clean way around them. 8-)

> 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.

I see.

>> 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.

I think that's it: 
If I recall correctly, there was a kernel version check (!) that
managed to reject kernels which did not have the bug.  And combined
with the workaround failing, this led to non-functional programs.

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

[Moritz Mühlenhoff]

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:
> 
> 

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

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

[Moritz Mühlenhoff]

Catching up on this...

> > This leaves Debian with two options:
> > * Keep it out of a stable release and accept that it's good enough
> >   if people just install whatever deb they currently find in testing/sid
> >   (works out well enough for most given that blob nature of Go!)
> 
> IMHO this is the most reasonable option and perhaps the only viable one.

Ultimately that's for the release team and/or CTTE to make a call on.

And this while discussion also needs the input of Janos as the current 
kubernetes
maintainer.

> > * 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.
> 
> I think Kubernetes have many more vendored 3rd party libraries than Firefox.
> IMHO we can not expect the same level of confidence for Kubernetes...

But each of their releases constitutes a bundle of third party libraries
they've vetted to work together, so this seems to work in practice? (as
can be seen by the 1.19 upload from today). Or maybe I'm missing the specific
concern of yours, is this about them missing fixes in their bundled libs?

Cheers,
Moritz