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.