Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)
On Wed, 24 Jan 2024 at 11:42, Simon Josefsson <simon@josefsson.org> wrote:
>
> Simon Josefsson <simon@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.
Reply to: