Bastian Blank <wa...@debian.org> writes: > Hi Simon > > On Sun, Jan 14, 2024 at 10:47:18AM +0100, Simon Josefsson wrote: >> As an analogy, consider the ./configure scripts that is generated by >> autoconf during build of many packages. The script typically generate >> code that is put into config.h that is used (statically) during >> compilation of the binaries that are shipped by Debian. > > Could you show an example, where there is actually code injcted in this > stage? And then, this is vendoring, not static linking. > >> You could also compare how the source-level reuse-library gnulib is used >> by many essential packages (coreutils, grep, sed, awk, tar, etc), with >> large code-reuse that influences the installed binaries. A security >> sensitive bug in gnulib would require rebuild of many packages. > > That is not static linking, this is vendoring. And can you show that > GNU utils don't fix security bugs on this vendored lib? > >> My suggestion is that we relax or remove the Go/Rust statement in future >> release notes. > > No. You described completely different circumstances. > > Or do you have a practical solution for the static linking problem, not > the vendoring problem that you actually compared it against?
Right, these are slightly different technical problems, but as far as the brief discussion in the release notes -- https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#golang-static-linking -- I think the relevant aspect is identical: package X in Debian contains an embedded copy of code whose corresponding source code is in package Y in Debian, and fixing a security problem in Y will require rebuilding X and the entire dependency chain between X and Y that carry the code that ends up in X. 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. The problem with dependencies are more obvious for Go/Rust code but I think we always have had that problem anyway. As for solutions, isn't the solution to both vendoring or statical linking the obvious one? You will have to rebuild all packages that contain the security vulnerability. Maybe I'm missing how these two problems result in different problems for the security team? /Simon
signature.asc
Description: PGP signature
