Le mar. 16 janv. 2024 à 11:00, Simon Josefsson <si...@josefsson.org> a écrit :
> 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. > I naively believed that golang-* packages expressed those dependencies with "Built-Using". Jérémy
