Paul Wise <p...@debian.org> writes: > On Mon, 2024-01-15 at 10:17 +0100, Bastian Blank wrote: > >> I asked for practical solutions, not theoretical ones. We don't have a >> suitable way to rebuild all packages just because right now. > > There are some ideas on the static linking wiki page: > > https://wiki.debian.org/StaticLinking > > Probably the most practical solution for today would be to use a build > info database to find out which builds had installed binary packages > containing insecure statically linkable files of any kind, then rebuild > the source packages that were affected. There is a 2019 demo here: > > https://salsa.debian.org/bremner/builtin-pho/-/blob/master/demos/needs-rebuild.sh > https://www.cs.unb.ca/~bremner//blog/posts/builtin-pho/ > > This may mean rebuilding more packages than were really needed, > but a more exact method would require full tracing of input data to > output data during builds being added to all toolchains, which seems > like a much longer term project than buildinfo based rebuilds.
Rebuilding a bit more than what is strictly needed sounds fine as a first solution to me. 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. What is the problem with that approach to handle security problems in a Go package for trixie? I'm sure the number of packages to rebuild could be reduced in various clever ways, but until we have tooling to automate that, a naive but costly approach seems feasible, unless i'm missing something. How large is the gap between tracing buildinfo information and simply relying on Build-Depends? Isn't the gap between using Build-Depends and the buildinfo-approach only concerning the always-assumed-to-be-installed packages like libc or /bin/sh which I never seems to recall if they are what build-essential installs, or what the policy manual says it should do, or what 'Essential: yes' implies, or 'Priority: required' implies, etc. For Go packages I don't think they are relevant in practice. /Simon
signature.asc
Description: PGP signature
