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".
Jérémy