Re: new kubernetes packaging
Sean Whitton <spwhitton@spwhitton.name> writes:
> Thank you for your e-mail. I agree with you that security support is
> the most pressing reason to avoid piles of vendored code, and you make
> an interesting argument regarding how it can be difficult to provide
> security fixes if our refusal to use vendored code means we lag too far
> behind upstream.
> I am not sure, however, that your argument applies to security updates
> to our stable releases. These updates are almost always a matter of
> backporting small fixes, rather than updating to new upstream releases.
> And for backported fixes, vendoring makes things much harder.
I think this calculus is not entirely obvious.
What you say is true if the library is used by multiple applications in
Debian (although it's still not as good of a story with Go as it is for
C). We can backport a patch to that one library, and then rebuild the
applications that incorporate it.
However, if a library exists in Debian solely because it is a dependency
of some sprawling application and isn't used by other things, it may be
easier to do a security update if it's vendored. There are, at the least,
fewer packages to rebuild, and the testing story is slightly more
straightforward.
Possibly more significantly is how the flow of security advisories work.
If the advisory is likely to come from Kubernetes and their security fix
release is a point release update to their package including the vendored
modules, we can potentially adopt the "sane upstream stable point release"
policy and just update stable to their point release. (Kubernetes does
maintain long-lived stable branches, although I don't know how stringent
they are about what changes they're willing to take in the stable
branches.) In this case, we create a bit more security work by separately
packaging the dependencies, since we now have to trace down the package
that corresponds to a Kubernetes security advisory and update it.
This of course doesn't apply if the individual libraries are releasing
their own security advisories.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: