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 ADE32158041 for ; Sat, 6 Apr 2024 16:15:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B7057E29F8; Sat, 6 Apr 2024 16:15:41 +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 60348E29F1 for ; Sat, 6 Apr 2024 16:15:41 +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: <92ef54a0-7a49-49f3-b3cc-d38a2b9adebd@ehuk.net> (Eddie Chapman's message of "Sat, 6 Apr 2024 12:57:23 +0100") Organization: Gentoo References: <875xwy8wxo.fsf@gentoo.org> <963ef0b6-7c2a-4730-b09d-5a829c3ff4c0@gmail.com> <92ef54a0-7a49-49f3-b3cc-d38a2b9adebd@ehuk.net> User-Agent: mu4e 1.12.2; emacs 30.0.50 Date: Sat, 06 Apr 2024 17:15:37 +0100 Message-ID: <877cha31sm.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: 8ecde2c2-ebc0-4fe5-8a60-ac51d3981728 X-Archives-Hash: 9043fa3a7864cc15023bc208cf6a7dfb Eddie Chapman writes: > On 04/04/2024 15:24, Eddie Chapman wrote: >> Since there appears to be some interest I'll put together a single email >> to the list later today detailing everything, as I needed to do more >> things overall in addition to replacing /usr/bin/xz. > > Below is a guide I've written to removing app-arch/xz-utils in case > anyone else wants to do so. Attached is the current version of the > Bash wrapper script I now use in place of /usr/bin/xz > > Comments, corrections on anything technical in the guide or script are > welcome, apart from flames about how this is ridiculous and > unnecessary :-). For an experiment I'm doing (distinct from trying to purge xz-utils, just verification work), I've packaged the following: * app-arch/gxz (pure Go impl.) * app-arch/7zip (7zip upstream are supporting Linux now, app-arch/p7zip was an unofficial port) You might find those useful too. At a glance, it appears https://github.com/fpgaminer/rust-lzma and https://github.com/gendx/lzma-rs don't provide executables - just a library - so I didn't bother looking further. > > Best wishes, > Eddie > > > ==== Guide to removing xz utils on a Gentoo system ==== > > [...] > There is one significant thing that breaks, which is Gemato > (app-portage/gemato). Gemato requires lzma support in core python in > order to do GPG signature verification. This means you will have to > say goodbye (for now) to verifying upstream GPG signatures on > distfiles, and verification of Portage metadata after doing an emerge > --sync. These features have been added to Portage relatively recently > (2022?) so are "nice to have", without them your system is just less No.. much older. It was introduced around the time of the github mirror being hacked. It's not just theatre! Like, this is very much NOT hypothetical. It's not just about metadata, it's about the ebuilds if using rsync, or the whole git checkout if using git. > hardened, but still with the very high level of security that Gentoo > systems have has always had prior to these features, in my > opinion. Personally I can live without them for now. Verifying hashes > in Manifest files still works fine and that's the main thing. You may > disagree in which case, well, don't do this then. I'm going to figure > out an alternative way I can verify Portage metadata soon, as there > are other ways if you are creative. See grobian's reply which should help. > [...] > - Portage binary packages: You cannot use xz compression if you create > Portage binary packages. You will need to use one of bzip2, gzip, > lz4, lzip, lzop, or zstd in BINPKG_COMPRESS in make.conf instead of > xz (if that is what you were using, or is it the default?). I have zstd is the default for "new" installs (since a few years ago), yeah. > [...] > - sys-apps/fwupd might stop working properly (though it will still > build fine) due to what you have to change with dev-libs/libxmlb > below. I'm not sure as I haven't checked yet, I just suspect it > will. So bear that in mind if you need to rely on sys-apps/fwupd at > the moment. But this "might" is temporary, upstream has now decided > to make lzma optional, so this will trickle down to Gentoo soon. Just for completeness, this is https://blogs.gnome.org/hughsie/2024/04/03/fwupd-and-xz-metadata/. > [...]