Adam Borowski <kilobyte@angband.pl> writes: > On Mon, Jan 15, 2024 at 10:17:17AM +0100, Bastian Blank wrote: >> On Sun, Jan 14, 2024 at 04:24:57PM +0100, Simon Josefsson wrote: >> > Isn't that what the text refers to? Vendoring and static linking are >> > two examples of the same problem that the security team may encounter. >> >> We accept vendoring of autoconf/automake/gnulib distro wide. > > We _did_ accept that in the past, but these days you get smacked with a RC > bug for not building from source. What do you mean? Can you show me _any_ package in Debian that re-bootstrap itself using gnulib during package build? If by source you mean the source code in gnulib, not the vendored version shipping with many packages. If a security bug is found in gnulib code, one approach to fix it would be to patch the Debian gnulib package, and then automatically rebuild all packages that uses that gnulib function. I believe it is rare for packages in Debian to re-bootstrap itself from gnulib sources. Look at coreutils, sed, grep, tar, wget, libidn2, etc, none of them do that. Certainly not a RC bug. The situation now when a security bug in gnulib is found, you will have to patch all packages using that code manually per-package. >> The vendoring of gnulib, well, is old and maybe you could >> show that it is a problem in the sources that have it, aka they don't >> handle security fixes and at the same time don't change the library. > > Gnulib has not been useful for ages, thus packages still shipping vendored > copies are harmless -- functions that gnulib was meant to provide > implementation for were missing on ancient unices like HP-UX or SCO that > are long dead by now. A glance at recent commits in gnulib shows a lot of > retrocomputing names: Windows, OS/2, MacOS 10.5, AIX, on hardware of that > level of recency. It's not used for new ports: the most recent reference > to riscv in commit messages is from _2018_. I think you underestimate how often gnulib is used, and how well it works on modern platforms, and how much gnulib code is used that's not in glibc or other system shared libraries. I assume coreutils, sed, tar, gzip etc were important bootstrapping packages for riscv, and they all build fine thanks in large extent due to gnulib being written in a architecture independent way. /Simon
Attachment:
signature.asc
Description: PGP signature