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

[Eddie Chapman <eddie@ehuk.net>]

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