On Thursday, 22 October 2020 2:22:11 AM AEDT Sean Whitton wrote: > 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'm not a member of security team but I want to share my prospective on this.
To us what matters is what we can do about vulnerability in situation where
the problem has been identified and fixed upstream, in the particular
library.
When a library is packaged separately, this is a matter of patching/updating
a particular library then re-building depending packages.
With vendored libraries, we have no control as patching arbitrary versions of
all instances of vendored library is a very bad option that is practically
unsustainable. Even tracking of vendored libraries is difficult.
So in case of vendored libraries we can rely on "Oracle model" when upstream
releases an update of a software where vendored library is patched so we ship
the whole bundle. This is the worst option because we have no control and
because we have to rely on faith in good upstream maintenance.
But here lies the problem. Kubernetes have bad dependency hygiene and poor
abolity to control their enormous vendor mess (burden). With hundreds of
vendored libraries they have large surface for problems and limited ability
to track and respond. Just like we know from experience, an attempt to update
a vendored library may lead to FTBFS and that's why upstream is reluctant to
make changes to vendored libraries, unless when they absolutely have to.
Kubernetes can not effectively address issues in "vendor/" space.
So my conclusion about security support of upstream Kubernetes is that it is
can not be done effectively in either case. There are greater chances for
meaningful security maintenance when most dependency libraries are un-
vendored. With most libraries vendored, there is less security maintenance
burden to us, but the outcome is no better.
--
All the best,
Dmitry Smirnov
GPG key : 4096R/52B6BBD953968D1B
---
No snowflake in an avalanche ever feels responsible.
-- Stanisław Jerzy Lec
signature.asc
Description: This is a digitally signed message part.
