Stephan Verbücheln <verbuecheln@posteo.de> writes: > On Sat, 30 Dec 2023 12:47:48 +0000 Colin Watson <cjwatson@debian.org> > wrote: >> I also feel that something security-critical like this that's >> labelled by upstream as "still experimental" probably shouldn't >> be in a Debian release. > > It is written in Go. The problem of Go library support in Debian should > also be considered for a security-critical tool like this. > > https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#golang-static-linking Interesting -- what is the current thinking about this problem? The more I think about it, I think it seems unfair to categorize this as a Go/Rust problem. 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. Consider further that these configure scripts would put security buggy into config.h, coming from autoconf internally or some wildly used M4 macros. How would the security team handle that situation? Perhaps by patching autoconf to fix the problem and rebuild all the packages that are affected by that bug, and release them as a (potentially large) security update. This is a similar situation to the Go/Rust problem that the link above describes. Yes I know, historically config.h has been quite small, so the problem hasn't been that significant, but have a look at a config.h from a couple of large project today. Compare an earlier large-scale-affecting build-tool bug in automake -- https://lists.gnu.org/archive/html/automake/2012-07/msg00022.html -- which happened to have mild consequences because 'make distcheck' is rarely run by most users or even during package builds, and the generated code didn't end up in the installed binaries. But it could happen in a 'make all' or a 'make check' target too, or affect code that actually influence the installed binaries. 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. My suggestion is that we relax or remove the Go/Rust statement in future release notes. /Simon
Attachment:
signature.asc
Description: PGP signature