[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal for how to deal with Go/Rust/etc security bugs (was: Re: Limited security support for Go/Rust? Re ssh3)



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?

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?

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature


Reply to: