From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DE845158041 for ; Sun, 31 Mar 2024 01:25:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 58AFAE29F5; Sun, 31 Mar 2024 01:25:54 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 10E0AE29EE for ; Sun, 31 Mar 2024 01:25:53 +0000 (UTC) From: Sam James To: "Eddie Chapman" Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo In-Reply-To: (Eddie Chapman's message of "Sat, 30 Mar 2024 03:07:13 -0000") Organization: Gentoo References: User-Agent: mu4e 1.12.2; emacs 30.0.50 Date: Sun, 31 Mar 2024 02:25:49 +0100 Message-ID: <87o7avdwf6.fsf@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain X-Archives-Salt: 63d489a4-353a-4125-89e3-41cc5458938b X-Archives-Hash: 058c52c27555004377af0a93cd2d389f "Eddie Chapman" 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