Re: What to do when DD considers policy to be optional? [kubernetes]
On Wed, 25 Mar 2020 02:07:13 +0100
Marco d'Itri <md@Linux.IT> wrote:
> On Mar 24, Russ Allbery <rra@debian.org> wrote:
> [...]
> The main reason for mostly forbidding vendored libraries has been that
> the security team rightly argues that in the event of a security issue
> it would be too much work to 1) hunt each package using a vendored
> library and 2) patch and rebuild all of them.
> This does not really matter for Go and Rust software because 1) the list
> of (vendored) dependencies can be extracted automatically at build time
> and 2) all this software would have to be rebuilt anyway since these
> languages do not support or do not use dynamic linking.
>
> Also, shared libraries save memory when multiple programs using them are
> run concurrently, but nowadays this kind of saving is rarely meaningful.
My point earlier was that it's not just a security problem. We have established
that Debian does, and will continue to, care about fulfilling license
obligations, including distributing license and copyright information with the
package.
Bluntly put, I have yet to see a project that doesn't treat 'vendor/' as a black
box of collected libraries. These directories are rarely reviewed and it is
trivial (default) to wind up including extra libs between builds. Even if it's
possible to restrict that list, I doubt it would be done.
I was (pleasantly) surprised to see d/copyright updated in this package.
However, this is not maintainable-
https://sources.debian.org/src/kubernetes/1.17.4-1/debian/copyright/
> Because of these reasons maybe we should consider supporting vendored
> libraries in some cases.
My opinion is still a very hard "No."
This sounds (to me) rather akin to- "since app devs tend to be lazy, should we
be the same?"
One last thing to consider... NEW reviews are already an intense process. If
this package hit NEW /and/ we allowed vendored libs, you could safely expect me
to never complete that particular review. I doubt I'm the only one; that's
essentially ~200 package reviews wrapped into 1.
--
Michael Lustfield
Reply to: