Simon Josefsson <si...@josefsson.org> writes: >> > 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. ... > 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.
Having reflected a bit, and learned through my own experience and
others' insights [1] that Go Build-Depends are not transitive, I'd like
to update my proposal on how to handle a security bug in any Go/Rust/etc
package and the resulting package rebuilds:
To fix a security problem in package X, which is used during build
(through statical linking, vendoring, or some other mechanism) to
build package A, B, C, ... you need to rebuild all packages that
Build-Depends on X (lets call this step 1) and all packages that
Build-Depends on any of the packages that will be rebuilt during step
1. This rebuild process is iterated until no more packages remains to
be rebuild, and all packages have been rebuilt using newly rebuild
packages. If there are cyclical dependencies (which unfortunately are
common), you have to loop until all packages have been rebuilt with a
clean dependency chain, and detect the loop and stop rebuilding. If
there are FTBFS errors during the rebuilds, this will have to be
patched too.
Yes, for a low-level Go package (e.g., golang-golang-x-net-dev), this
will mean rebuilding almost all of the Go packages in Debian and publish
them in a security advisory.
This algorithm can be optimized (i.e., reduce the number of packages to
publish in an advisory) by either of:
1) using information from Built-Using: (which was not designed for
this purpose, so this is fragile) or *.buildinfo.
2) by dropping all 'Architecture: all' packages that does not embedd
the buggy code.
The last optimization 2) would reduce the number of Go packages to
publish significantly, as it would drop most golang-*-dev packages. I
think this actually makes this process feasible in practice, as there
are relatively few binary packages written in Go.
This method applies to non-Go/Rust too, if there are such security
problems and reverse build chains.
I think all of this (except maybe the optimization 2) which requires
code comparisons) can be automated in a GitLab pipeline for higher
confidence of the result.
/Simon
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806481#58
signature.asc
Description: PGP signature
