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
