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 11:07:17 -0500	[thread overview]
Message-ID: <2423c126-114e-751a-27f4-9b541b311a66@gmail.com> (raw)
In-Reply-To: <d696ac9577fae8e6e3b28aab4e3f4fe0.squirrel@ukinbox.ecrypt.net>

Eddie Chapman wrote:
> Michał Górny wrote:
>> On Sat, 2024-03-30 at 14:57 +0000, Eddie Chapman wrote:
>>
>>> Note, I'm not advocating ripping xz-utils out of tree, all I'm saying
>>> is wouldn't it be nice if there were at least 2 alternatives to choose
>>> from? That doesn't have to be disruptive in any way, people who wish to
>>> continue using and trusting xz-utils should be able to continue to do so
>>> without any friction whatsoever.
>> So, you're basically saying we should go out of our way, recompress all
>> distfiles using two alternative compression formats, increase mirror load
>> four times and add a lot of complexity to ebuilds, right?
>>
>> --
>> Best regards,
>> Michał Górny
>>
> Yes that's a very good point, that was something I was wondering in
> weighing up both sides, what the costs would be practically, as I don't
> know the realities of running Gentoo infrastructure. And maybe the costs
> is just too high of a price to pay.
>
> I wonder if increased use of git repos rather than distributed tarballs
> could be part of a solution to those issues, although that could put quite
> a storage burden on every user. Unless they were all shallow git pulls and
> the user could optionally choose to tar up the git directory after clone
> with compression.  But yes granted then there is even more ebuild
> complexity.
>
>
> .
>

There is a lot of unknowns out there.  From what I've read, the person
responsible for writing the code inserted this hack.  There may be no
way to prevent this.  Basically, the person that should have been
trusted with this code violated that trust.  Why is unknown but I'm as
curious about that as anything.  It's like when someone goes to a
grocery store to buy a tomato.  They want organic and there is a organic
sticker on the tomato.  You either trust that sticker, and the
person/company who put it on there, or you don't trust that sticker at
all and avoid buying all tomatoes.  The trust starts with the
person/company that puts that sticker on the tomato.  The person who was
trusted with that code, broke that trust.  There is likely hundreds of
packages out there in the exact same position.  Any package that has few
or only one person writing the code can do the same thing. 

While this should be analyzed as more info comes in, right now, we
should let the devs get us back to as safe a place as possible.  Since
it appears to affect systemd users who don't use Gentoo, which is a huge
target, they certainly need to react as quickly as they can to the devs
actions.  Let's just not overreact just yet.  The devs has rolled back
to a safe, safer, version.  Let time and more info sort this out. If it
is needed, xz will go away, which shouldn't come as a surprise.  I'm
sure the person who did this will never get that trust back. 

Long term, this is going to be interesting to see what all gets
revealed.  The why is one thing.  Another is how to prevent if it can be
at all. 

I'm going back to my hole now. 

Dale

:-)  :-) 

P. S.  Links that some may want to follow, instead of a -dev thread. 

https://bugs.gentoo.org/928134

https://forums.gentoo.org/viewtopic.php?p=8821925


  parent reply	other threads:[~2024-03-30 16:07 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 [this message]
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=2423c126-114e-751a-27f4-9b541b311a66@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