Re: Proposal for how to deal with Go/Rust/etc security bugs
On Wed, 24 Jan 2024 at 13:34, Simon Josefsson <simon@josefsson.org> wrote:
>
> Luca Boccassi <bluca@debian.org> writes:
>
> >> 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
>
> Definitely - that's roughly the model we have today, right? So no
> action needed to preserve status quo of option B.
>
> I want to explore if there is a possibility to change status quo, and
> what would be required to do so.
What's required is talking to the language ecosystem owners and
convince them to support a stable ABI and dynamic linking, and in
general to care about the distribution use case. Otherwise it's just
an unwinnable uphill battle that consumes a ton of scarce resources
(developers time), and is simply hopeless.
> Given how often gnulib is vendored for C code in Debian, and other
> similar examples, I don't think of this problem as purely a Go/Rust
> problem. The parallel argument that we should not support coreutils,
> sed, tar, gzip etc because they included vendored copies of gnulib code
> is not reasonable.
As it was already explained, this is a misleading example that has
nothing to do with the problems of the Go/Rust ecosystem.
Reply to: