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 12:26, Johannes Schauer Marin Rodrigues
<josch@debian.org> wrote:
>
> Hi,
>
> Quoting Luca Boccassi (2024-01-24 12:59:38)
> > 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.
>
> how does that work for those applications that require rust, go and friends?
> Are you proposing that everything that needs them should be be distributed by a
> flatpak or similar mechanism instead?
Those applications are not shipped in the distribution. If somebody
wants to use them, they'll have to figure it out, just like for
everything else that is not shipped in the distribution, which is
already a subset of all available software in the world.
> Just a few days ago I tried building mesa from experimental (otherwise there
> are severe graphics glitches on my platform) on bookworm and everything worked
> except its rust build dependencies. I had no luck trying to backport those
> parts of rust that I needed and even if it had worked, it would've meant
> backporting dozens of rust packages just to have a backport of mesa. It seemed
> way simpler to just disable the mesa component that requires rust and call it a
> day. But that probably doesn't work for all applications and maybe sometimes
> the component written in rust is actually what you want. And in case of mesa, a
> flatpak of it probably would also not've helped as that would've meant that I
> need to run everything that I want to run with a more modern mesa based on that
> flatpak, right?
>
> So how is option B a solution in practice?
You have found first-hand the exact problem with this ecosystem. Now
try to imagine doing that for 30k packages, all vendoring, pinning and
static linking against each other at different, incompatible versions.
Again, the solution in practice is to simply disable or patch out
those components, and if somebody needs them, they can complain to
upstream and ask them for a solution, if there is one. If there isn't,
though luck. And yes, that is not great - but neither are all other
options, so it seems much wiser to me to push responsibility where it
belongs - with the upstreams choosing to use such ecosystems, and the
owner of said ecosystems choosing to make them incompatible with the
distribution model, as they are in the best position to solve the
problem(s) that happen due to their design choices.
Reply to: