public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Dale <rdalek1967@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
Date: Sat, 30 Mar 2024 02:06:26 -0500	[thread overview]
Message-ID: <1671d927-55d5-6f01-2b54-b33981406945@gmail.com> (raw)
In-Reply-To: <20240329204315.3b29449b@Akita>

orbea wrote:
> On Sat, 30 Mar 2024 03:07:13 -0000
> "Eddie Chapman" <eddie@ehuk.net> wrote:
>
>> Given what we've learnt in the last 24hrs about xz utilities, you
>> could forgive a paranoid person for seriously considering getting rid
>> entirely of them from their systems, especially since there are
>> suitable alternatives available.  Some might say that's a bit
>> extreme, xz-utils will get a thorough audit and it will all be fine.
>> But when a malicious actor has been a key maintainer of something as
>> complex as a decompression utility for years, I'm not sure I could
>> ever trust that codebase again. Maybe a complete rewrite will emerge,
>> but I'm personally unwilling to continue using xz utils in the
>> meantime for uncompressing anything on my systems, even if it is done
>> by an unprivileged process.
>>
>> I see that many system package ebuilds unconditionally expect
>> app-arch/xz-utils to be installed simply to be able to decompress the
>> source archive in SRC_URI. So simply specifying -lzma on your system
>> isn't going to get rid of it.
>>
>> No one could have been expected to foresee what's happened with
>> xz-utils, but now that it's here, perhaps Gentoo (and other projects
>> that do) should consider not relying on a single decompression
>> algorithm for source archives, even just as an insurance against some
>> other yet unknown disaster with one algorithm or another in future?
>>
>> And yes I'm sure there will be individual packages that currently
>> absolutely need xz-utils installed during the build process, and one
>> or two that absolutely have to have it available at runtime, but those
>> bridges can be crossed as and when.
>>
>> Eddie
>>
>>
> I think this is an overreaction and we should wait for the dust to
> settle before making drastic disruptive changes.
>
>


From the news item email: 


"Impact
======

Our current understanding of the backdoor is that is does not affect
Gentoo systems, because

1. the backdoor only appears to be included on specific systems and
Gentoo does not qualify;
2. the backdoor as it is currently understood targets OpenSSH patched to
work with systemd-notify support. Gentoo does not support or include
these patches;

Analysis is still ongoing, however, and additional vectors may still be
identified. For this reason we are still issuing this advisory as if
that will be the case."


When I started reading it, I was concerned as well as I know it is used on my system.  However, when I got to the part about it not likely to affect Gentoo, my level of concern dropped significantly.  If this is still true, there's no need to be concerned.  If things has changed and it does affect Gentoo, I'm sure there will be changes made that will either fix the issue for good or at least provide a workaround until a solution is found.  Gentoo has some awesome devs. Someone will find a solution.  I notice that it has already been changed in the tree to a version that does not have the malicious code.  That alone should be a solution until a new plan is made.  

While I'm a little concerned and hope for a proper solution, I'm not to worried.  I certainly don't think we should overreact this early.  Give the devs and upstream time to work this out.  

Just a users opinion.  

Dale 

:-)  :-)  



  reply	other threads:[~2024-03-30  7:06 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 [this message]
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
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=1671d927-55d5-6f01-2b54-b33981406945@gmail.com \
    --to=rdalek1967@gmail.com \
    --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