tis 2024-01-16 klockan 11:22 +0100 skrev Jérémy Lal: > > > Le mar. 16 janv. 2024 à 11:00, Simon Josefsson <simon@josefsson.org> > a écrit : > > Paul Wise <pabs@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". True, but I was thinking of a solution that would not be Go-specific. I realized that there is one problem with my approach: consider if package A was built via Build-Depends package B of version X and that later package B is upgraded to X+1 in Debian. Then if a security problem happens in B we need to rebuild A. It may be that package A no longer builds due to some incompatibility between version X and X+1 of B. This would not be noticed until a full rebuild of an archive is done, or when the security teams wants to rebuild the transitive closure of the Build-Depends graph for a package. I still think this is something we just need to be prepared to handle, by patching packages to fix the build problem in whatever way is appropriate. It will require some more patching to really fix the security problem, and allow packages to be rebuilt with the new version. /Simon
Attachment:
signature.asc
Description: This is a digitally signed message part