On Wed, 24 Jan 2024 at 11:42, Simon Josefsson <si...@josefsson.org> wrote: > > 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:
There's always option B: recognize that the Rust/Go ecosystems are not designed to be compatible with the Linux distributions model, and are instead designed to be as convenient as possible for a _single_ application developer and its users - at the detriment of everybody else - and for large corporations that ship a handful of applications with swathes of engineers that can manage the churn, and it is not made nor intended to scale to ~60k packages or whatever number we have today in unstable. And simply stop attempting to merge these two incompatible ecosystems against their will, at the very least until and unless they reach feature and stability parity with the C/C++ ecosystems - stable API/ABI and dynamic linking by default. There are many ways to ship applications today that are much better suited for these models, like Flatpak, where the maintenance burden is shifted onto those who choose to opt in to such ecosystems.
