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 23C31158041 for ; Tue, 2 Apr 2024 19:32:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7A995E2A77; Tue, 2 Apr 2024 19:32:44 +0000 (UTC) Received: from james.steelbluetech.co.uk (james.steelbluetech.co.uk [78.40.151.100]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 26126E2A74 for ; Tue, 2 Apr 2024 19:32:43 +0000 (UTC) Received: from [10.0.5.25] (tv.ehuk.net [10.0.5.25]) by james.steelbluetech.co.uk (Postfix) with ESMTP id 10AF5BFC18; Tue, 2 Apr 2024 20:32:42 +0100 (BST) DKIM-Filter: OpenDKIM Filter v2.10.3 james.steelbluetech.co.uk 10AF5BFC18 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ehuk.net; s=default; t=1712086362; bh=sBNUiWd+VPn+YIB+8Nm3ZF4MA2VbnwCvSaRLQQup2NI=; h=Date:Reply-To:Subject:To:References:From:In-Reply-To:From; b=If6jQcdKNkMADMr86RPMoCEjgKTn0oQKBGuvk6qFe1tL4HBFU2ug7xApcXHhWGWT3 CYDPPYAqex+6XZRmcrHGdNFiLedD27g/UT/XKYt+xTthY4V7TwtiKHcnIUQekL4CHK GKelLC3DqOjMfJmBwWykc7tT1f1+E6eUp76b2hNgQtUsDYXIXRJPItICVU53H0UWGR 0J6bgt3HQeCRb4/3YLFjqhzscS0iS0ODi54xnZpNJCXqhMlTHyvWfJ5irtgtAKlcqb tBo19T9z8FoBb78cJuJ4gvfUACUGAxtURLbVNFMFXoYx7px1IR4fdw69kfvEl+qBZK GUo4C3WWc6vRw== Message-ID: Date: Tue, 2 Apr 2024 20:32:41 +0100 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 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo To: gentoo-dev@lists.gentoo.org, Azamat Hackimov References: Content-Language: en-GB From: Eddie Chapman In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang X-Archives-Salt: f0a693ba-2c30-4619-8ba9-37a36c3e806f X-Archives-Hash: ef8cc8494a5a222bf7c2305487a20a12 On 01/04/2024 15:56, Azamat Hackimov wrote: > There is no problem in the XZ/LZMA format itself as the reference > algorithm is not compromised. It's all about trust between developers > of application and developers of distribution. If you lost trust to > xz-utils's developers, you may use alternatives like app-arch/pxz or > app-arch/pixz. I don't see reasons why we should change format instead > of changing a tool. > Hello Azamat, Yes, I have no issue with the format at all, just with the xz utils project. But I was suggesting to have support for two compression algorithms as an improvement for the future, in case of some unknown other major problem with one of them emerges in future. I suppose kind of a similar reasoning, but not quite the same, that we have BLAKE2B and SHA512 hashes. But there are severe practical problems for Gentoo infra resources with having two of course. Thank you for the pointer to app-arch/pxz and app-arch/pixz. I've had a close look at them both but sadly they are not suitable as they both rely on the xz utils project to do the main work. Once calls the xz exe and the other links against liblzma. I have been looking around a bit since Friday at what true alternatives (no relying on liblzma) there are to just decompress existing XZ/LZMA binaries. There is p7zip which is a command line fork of 7zip that's been around a good while. However in the years since that fork was created the 7zip project themselves have begun doing source code releases with build instructions, with the command line tool apparently working fine. On balance the upstream 7zip actually looks like a better option than p7zip now since p7zip maintenance has stagnated somewhat. On the one hand 7zip is actively developed, of course because of the large Windows userbase, and security fixes would be available immediately when a new release comes about (there were sec issues fixed in 7zip last year for example which didn't make it into p7zip in a timely fashion). But on the other hand most distros have used p7zip and I've only seen Arch and Debian that currently package the 7zip releases, so the latest 7zip releases have had only minimum real world testing and code scrutiny in the Linux world (although it's likely much of the code will still be the same as what it was when p7zip was forked, so in that sense at least a significant portion of the code has had wider testing, in a manner of speaking). Still, I'm not sure about 7zip, doesn't seem ideal. Thomas Gall, elsewhere in this thread, pointed out a pure Rust implementation which is interesting. https://github.com/gendx/lzma-rs The GH page says it supports decompression of "LZMA, LZMA2 and a subset of the .xz file format". If anyone else knows of any other true alternatives please do let me know. I'm currently looking into the feasibility of hacking my Gentoo installations so that .xz distfiles are decompressed during the ebuild process using an alternative implementation, allowing me to get rid of xz utils. Thanks, Eddie