Bastian Blank <wa...@debian.org> writes: > On Tue, Jan 16, 2024 at 10:59:30AM +0100, Simon Josefsson wrote: >> Rebuilding a bit more than what is strictly needed sounds fine as a >> first solution to me. > > Building maybe. But how do you want to publish them? The security > archive is not made to handle that.
What is the limitation? Is it human time involved to rebuild and QA packages? Or the technical infrastructure related to publish security fixes? Or the hosting infrastructure to deliver the package upgrades via security.debian.org? Or something else? >> My naive approach on how to fix a security problem in package X which is >> statically embedded into other packages A, B, C, ... would be to rebuild >> the transitive closure of all packages that Build-Depends on X and >> publish a security update for all those packages. > > So if a fix to the net/tls module of go shows up (happens from time to > time), all go packages needs to be rebuilt? All Go packages that are affected by the security problem of net/tls, yes. That seems to be how the Go eco-system want things to be, the static linking nature is by design. Whether that is a good or bad design can be discussed, but it seems intentional and won't go away. My main point is that we have this situation in Debian already. Maybe vendoring via gnulib is a better example than config.h or statical linking though. Having being more exposed to the packaging aspects of Go projects in Debian recently, I am more sympathetic towards being conservative about offering security claims for these packages though. I wouldn't envy anyone trying to resolve a security vulnerability for a Go package in bookworm with many reverse dependencies. OTOH, I don't think it is sustainable to ignore security vulnerabilities in software that we ship. We just have to find a technical solution to solve whatever problems prevent us from being able to do that. /Simon
signature.asc
Description: PGP signature
