On Wed, Oct 21, 2020 at 08:22:11AM -0700, Sean Whitton wrote:
> Hello security team,
>
> The TC are being asked about src:kubernetes, and it would be good to
> hear from you about whether and how security support is a relevant
> consideration in determining whether the level of vendoring in that
> package is acceptable. Could you take a look at #971515 and perhaps
> give us some input, please?
I don't currently have the time to read through all the discussion backlog,
but let me try to "zoom out a bit":
The bigger issue here (independent of the whole vendoring aspect) is
how kubernetes can be supported in a stable release to begin with.
This was raised by Shengjing Zhu in #959685 before.
Upstream support only lasts for up to a year and it would be
presumptuous to pretend that we can seriously commit to fix
security issues in k8s for longer than upstream.
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!)
* 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").
If we follow the latter approach, then the current way k8s is packaged
is the only viable option (as otherwise the run time deps shipped
for 19.x would be incompatible with 20.x etc.)
Cheers,
Moritz
