"Eddie Chapman" <ed...@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
