public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Sam James <sam@gentoo.org>
To: Eddie Chapman <eddie@ehuk.net>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
Date: Sat, 06 Apr 2024 17:15:37 +0100	[thread overview]
Message-ID: <877cha31sm.fsf@gentoo.org> (raw)
In-Reply-To: <92ef54a0-7a49-49f3-b3cc-d38a2b9adebd@ehuk.net> (Eddie Chapman's message of "Sat, 6 Apr 2024 12:57:23 +0100")

Eddie Chapman <eddie@ehuk.net> 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/.

> [...]


  parent reply	other threads:[~2024-04-06 16:15 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-30  3:07 [gentoo-dev] Current unavoidable use of xz utils in Gentoo Eddie Chapman
2024-03-30  3:43 ` orbea
2024-03-30  7:06   ` Dale
2024-03-30 10:47     ` [gentoo-dev] " Duncan
2024-03-30 11:32     ` [gentoo-dev] " Rich Freeman
2024-03-30 14:57       ` Eddie Chapman
2024-03-30 15:02         ` Michał Górny
2024-03-30 15:17           ` Eddie Chapman
2024-03-30 15:29             ` Michał Górny
2024-03-30 15:59               ` Eddie Chapman
2024-03-30 16:07             ` Dale
2024-03-30 17:13             ` Re[2]: " Stefan Schmiedl
2024-03-30 17:36               ` Eddie Chapman
2024-03-31  1:41                 ` Thomas Gall
2024-03-30 23:49             ` Eddie Chapman
2024-03-31  1:36             ` Eli Schwartz
2024-03-30 15:23           ` orbea
2024-03-30 15:14         ` Rich Freeman
2024-03-30 17:19           ` Eddie Chapman
2024-03-31  1:25 ` Sam James
2024-03-31  1:33 ` Eli Schwartz
2024-03-31 11:13   ` Eddie Chapman
2024-03-31 11:59     ` Matt Jolly
2024-04-01  7:57       ` Eddie Chapman
2024-04-01 14:50         ` Eli Schwartz
2024-04-02  8:43           ` Eddie Chapman
2024-04-02 19:46             ` Eli Schwartz
2024-04-02 20:19               ` Eddie Chapman
2024-04-01 14:55         ` Michał Górny
2024-04-02  9:02           ` Eddie Chapman
2024-04-01 15:14     ` Kenton Groombridge
2024-04-01 15:40       ` orbea
2024-04-01 16:01         ` Kenton Groombridge
2024-04-01 16:21           ` orbea
2024-04-01 18:51             ` Kévin GASPARD DE RENEFORT
2024-04-01 20:07               ` James Le Cuirot
2024-04-02  6:32                 ` Joonas Niilola
2024-03-31 11:32   ` stefan11111
2024-04-01 14:56 ` Azamat Hackimov
2024-04-02 19:32   ` Eddie Chapman
2024-04-03 11:47     ` [gentoo-dev] " Duncan
2024-04-03 12:14       ` Sam James
2024-04-03 15:30         ` [gentoo-dev] " Eddie Chapman
2024-04-03 16:40           ` Michael Orlitzky
2024-04-04  3:20             ` [gentoo-dev] " Duncan
2024-04-04  3:49           ` [gentoo-dev] " Eli Schwartz
2024-04-04  8:32             ` Sam James
2024-04-04  8:34               ` Kévin GASPARD DE RENEFORT
2024-04-04 14:38               ` Eddie Chapman
2024-04-04 14:24             ` Eddie Chapman
2024-04-06 11:57               ` Eddie Chapman
2024-04-06 12:15                 ` Ulrich Mueller
2024-04-06 12:34                 ` Roy Bamford
2024-04-06 14:04                 ` Fabian Groffen
2024-04-07  6:44                   ` Eddie Chapman
2024-04-06 16:15                 ` Sam James [this message]
2024-04-07 11:24                   ` Eddie Chapman
2024-04-11  5:21                 ` Joonas Niilola
2024-04-12  7:18                   ` [gentoo-dev] " Duncan
2024-04-13  7:10                   ` [gentoo-dev] " Eddie Chapman
2024-04-03 12:22       ` [gentoo-dev] " Kévin GASPARD DE RENEFORT
2024-04-03 12:26         ` Kévin GASPARD DE RENEFORT
2024-04-04  1:41         ` Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877cha31sm.fsf@gentoo.org \
    --to=sam@gentoo.org \
    --cc=eddie@ehuk.net \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox