Re: Proposal for how to deal with Go/Rust/etc security bugs
Simon Josefsson <simon@josefsson.org> writes:
> I want to explore if there is a possibility to change status quo, and
> what would be required to do so.
> 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.
Since there are now a bunch of messages on this thread of people grumbling
about Rust and Go and semi-proposing not even trying to package that
software (and presumably removing python3-cryptography and everything that
depends on it? I'm not sure where people think this argument is going), I
wanted to counterbalance that by saying I completely agree with Simon's
exploration here.
Rebuilding a bunch of software after a security fix is not a completely
intractable problem that we have no idea how to even approach. It's just
CPU cycles and good metadata plus ensuring that our software can be
rebuilt, something that we already promise. Some aspects of making this
work will doubtless be *annoying*, but it doesn't seem outside of our
capabilities as a project.
Dealing with older versions is of course much more of a problem,
particularly if upstream is not backporting security fixes, but this is a
problem is inherent in having stable releases, that upstreams have been
grumbly about long before either Rust or Go even existed, and that we have
nonetheless dealt with throughout the whole history of Debian. There is
no one-size-fits-all solution, but we have historically managed to muddle
through in a mostly acceptable way.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: