Hello, On Tue 24 Mar 2020 at 03:14PM -07, Russ Allbery wrote: > 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. Right, if something is technically an independent language module but is used only by kubernetes, and we don't expect that to change, there's no need for it to be in its own source package just because it might seem tidier to us. I doubt that this is true of all the hundreds of dependencies presently bundled with kubernetes, however. > 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 is certainly a reasonable approach, if such releases aren't going to violate the expectations of users of Debian stable. I guess we'd have to see whether the Security Team are up for another package which gets updated in this way. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature