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

[Dmitry Smirnov]

On Wednesday, 28 October 2020 6:13:41 AM AEDT Moritz Mühlenhoff wrote:
> 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.

If Kubernetes can be supported then such support will be done by upstream,
but with extraordinary amount of dependencies (and upstream reluctance to 
manage them), I have very low confidence and low expectations for quality
of such support. The problem primarily is that Kubernetes vendors hundreds
of dependencies representing a large support surface. Effectively it is
"#include world" (or vendor world) situation. And when it comes to problems
in 3rd party vendored libraries, it iw worth remembering that Kubernetes 
don't own them.


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


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

-- 
Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

You have to start with the truth. The truth is the only way that we can
get anywhere. Because any decision-making that is based upon lies or
ignorance can't lead to a good conclusion.
-- Julian Assange, 2010


signature.asc
Description: This is a digitally signed message part.

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

[Moritz Mühlenhoff]

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