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 

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

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

Reply via email to