Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Sam James <sam@gentoo.org>]

"Eddie Chapman" <eddie@ehuk.net> writes:

> Given what we've learnt in the last 24hrs about xz utilities, you could
> forgive a paranoid person for seriously considering getting rid entirely
> of them from their systems, especially since there are suitable
> alternatives available.  Some might say that's a bit extreme, xz-utils
> will get a thorough audit and it will all be fine. But when a malicious
> actor has been a key maintainer of something as complex as a decompression
> utility for years, I'm not sure I could ever trust that codebase again.
> Maybe a complete rewrite will emerge, but I'm personally unwilling to
> continue using xz utils in the meantime for uncompressing anything on my
> systems, even if it is done by an unprivileged process.

My own view is that there'll be a time for introspection, reflection,
and discussion of changes once the crisis is over. We're not there yet.

But I don't think us fetching several variants of compression formats
and testing & verifying all of them is feasible.

I also think it's (and I don't mean this derogatorily towards you) naive
for people in general to suggest that this is really specific to xz at
all. Unfortunately, there's many. many projects this could've happened to.

>
> I see that many system package ebuilds unconditionally expect
> app-arch/xz-utils to be installed simply to be able to decompress the
> source archive in SRC_URI. So simply specifying -lzma on your system isn't
> going to get rid of it.
>
> No one could have been expected to foresee what's happened with xz-utils,
> but now that it's here, perhaps Gentoo (and other projects that do) should
> consider not relying on a single decompression algorithm for source
> archives, even just as an insurance against some other yet unknown
> disaster with one algorithm or another in future?

I think there's real discussions to be had about relying on dist
tarballs and such but I don't really see how we could try to avoid
compression algorithms.

>
> And yes I'm sure there will be individual packages that currently
> absolutely need xz-utils installed during the build process, and one or
> two that absolutely have to have it available at runtime, but those
> bridges can be crossed as and when.
>
> Eddie

thanks,
sam