Re: Proposal for how to deal with Go/Rust/etc security bugs
On Thu, 25 Jan 2024 at 16:11, Russ Allbery <rra@debian.org> wrote:
>
> 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.
Well, CPu cycles and metadata are not quite the whole story though. It
also takes a huge amount of extra engineering effort, both one-time to
completely rearchitect and reimplement the build and release
infrastructures to deal with this at scale, and ongoing to maintain
the additional complexities for the rest of the project's life. As you
well know, developers time is by far the scarcest resource of them
all.
Also, it means downloading and installing GBs of packages on every
security update, instead of a few KBs, for every user. While not as
bad as the resource issue, it's still not great.
Finally, as an opinion, quite frankly, it's not a very good design.
You can already run a distribution that does static linking for
everything and requires rebuilding the whole universe and then some
every time there's a one character change anywhere - take Yocto and
configure it to use Musl. Having used it for a long time now, it's
_really_ not good and I wouldn't recommend it to anybody. Matter of
taste of course.
Reply to: