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
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.
On Sat, Mar 30, 2024 at 3:06 AM Dale <rdalek1967@gmail.com> wrote:
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.
"not likely" is the best way to characterize this. The exploit has
not been fully analyzed, and it could have additional malicious behavior, either designed by its author, or perhaps even unintended by its author.
I just wanted to toss in that caveat, but agree that the defaults
deployed in Gentoo seem the most sensible for general use. There is
nothing magical about xz - ANY widely-used library could have something
like this embedded in it, and the attacker exploited what they had access
to in order to go after a configuration that was going to be widely
deployed and reachable (xz+deb/rpm+systemd+openssh). If the attacker had
an intended target that used gentoo+openrc and access to something in our supply chain, this could have been a vulnerability that only impacted
Gentoo.
I think the big lesson here is that FOSS continues to suffer from core dependencies that are challenged for resources, and that efforts to fix
this have to constantly keep up with the changing landscape. xz is going
on 15 years old, but I don't think it was nearly as commonly used until fairly recently.
libz has been a pretty well-known source of security flaws for ages
(granted, usually not intentional like this). It isn't too surprising
that in both cases compression libraries were targeted, as these are so widely depended on.
This is getting tangential, but part of me wonders if there is a
better way to do authentication. Programs like ssh tend to run as root so that they can authenticate users and then fork and suid to the appropriate user. Could some OS-level facility be created to allow unprivileged processes to run the daemons and then as part of the authentication
process they can have the OS accept a controlled and minimal set of data
to create the process as the new user and hand over the connection? PAM already has a large amount of control over the authentication process, so
it seems like we just need to change the security context that this runs
in. That's just brainstorming-level thinking though - there could be
obvious issues with this that just haven't occurred to me.
--
Rich
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.
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
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?
No, this is the the bad actor *themselves* being a
principal author of the software, working stealthily and in very sophisticated ways for years, to manoeuvrer themselves and their software into a position of trust in the ecosystem whereby they were almost able to pull off the mother of all security nightmares for the world.
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.
On Sat, 2024-03-30 at 15:17 +0000, 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.
Should we convert git repositories to Mercurial and Bazaar too, to avoid relying too much on a single tool?
--
Best regards,
Michał Górny
On Sat, Mar 30, 2024 at 10:57 AM Eddie Chapman <eddie@ehuk.net> wrote:
No, this is the the bad actor *themselves* being a
principal author of the software, working stealthily and in very
sophisticated ways for years, to manoeuvrer themselves and their
software into a position of trust in the ecosystem whereby they were
almost able to pull off the mother of all security nightmares for the
world.
This is entirely speculative at this point. It isn't certain that the
author is the one behind the exploit, and if they were, it is not known for how long their intentions were malicious, or even what their motivations were. It is also unclear what pseudonymous accounts with what projects
are associated with the attacker.
Michał Górny wrote:
On Sat, 2024-03-30 at 14:57 +0000, Eddie Chapman wrote:Yes that's a very good point, that was something I was wondering in
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
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.
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
On 3/29/24 11:07 PM, Eddie Chapman 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.
It suffices to downgrade to the version of xz before a social
engineering attack by a malicious actor to gain maintainership of the xz project.
Have you been linked to this yet? https://www.mail-archive.com/xz-devel@tukaani.org/msg00571.html
--
Eli Schwartz
On 3/29/24 11:07 PM, Eddie Chapman 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.
It suffices to downgrade to the version of xz before a social
engineering attack by a malicious actor to gain maintainership of the
xz
project.
Have you been linked to this yet? https://www.mail-archive.com/xz-devel@tukaani.org/msg00571.html
Wed, 29 Jun 2022 13:07:07 -0700
At the moment there is far too much of
a cavalier attitude about the whole thing being shown by too many,
including here I'm sad to see.
Hi Eddie,
On 31/3/24 21:13, Eddie Chapman wrote:
At the moment there is far too much of
a cavalier attitude about the whole thing being shown by too many,
including here I'm sad to see.
It's obvious that this is something that you are very worried about, but
I think that you need to take a deep breath and relax a little. I have
not seen a cavalier attitude towards this issue.
What I see instead are developers who have made an initial assessment
and disclosure, have taken some actions to mitigate the severity of the issue, and are carefully continuing their investigations (over a major holiday in large parts of the world) so that they can issue sane responses
to actual threats, and not a knee-jerk response like 'Gentoo should
re-encode all xzs in other formats' which, as was discussed above, adds significant complexity for no real benefit.
I've seen from your previous emails to the list that you know what
paragraphs are and how to use them to break up your content into digestible chunks. Please continue using them - it makes it significantly easier to respond to your ideas and gives off an aura of professionalism that you
will need if you want your concerns to be taken seriously and addressed directly.
Cheers,
Matt
On Mon, 2024-04-01 at 08:57 +0100, Eddie Chapman wrote:
I stand by and reiterate my view that there is far too much of a
cavalier attitude towards the matter in general out there including here
in Gentoo. But not in particular here, it is everywhere where this is
being discussed at the moment.
I would like to point out that the xz/sshd issue was primarily a social
one, not a technical one.
The primary problem in open source today isn't bad code. It's projects relying on overburdened, burned out maintainers. And on top of that, users who are complaining, demanding, outright hostile or primarily contributing
by walls of text on a mailing lists, that bring nothing to discussion
except for furthering the burnout of open source developers who are
actually trying to do something.
Think about that.
--
Best regards,
Michał Górny
On 4/3/24 11:30 AM, Eddie Chapman wrote:
Just to report I've been able to remove app-arch/xz-utils from my own
workstation, with 2412 packages installed and running kde. I'm going to
roll it out to my other gentoo systems which have a lot less stuff on
them so am confident will be fine. It's not completely trivial but not
as difficult as I imagined it to be, certainly something an advance
Gentoo
user could do if they wanted, with instructions. It does involve a
relatively small hack and functionality previously provided by xz-utils
is replaced by app-arch/p7zip.
I'd just like to clarify my previous posts: what you're describing here
is neat and productive and valid to my eyes. Actually, I wish this had been the topic of the *first* post in this thread. :)
Replacing implementations has several great uses. There's some prior art
in make.conf, but it doesn't go far enough:
PORTAGE_BZIP2_COMMAND
BINPKG_COMPRESS
BINPKG_COMPRESS_FLAGS
Disregarding the security component entirely, one might wish to use pixz
or pigz instead of the default programs. Why not 7zip as well?
In terms of security, this suggests an easy and simple way both to allow users to depclean xz-utils without sacrificing the ability to install packages using *.tar.xz sources, and for Gentoo to roll out an update that would do this distribution-wide if necessary via a trivial configuration change.
https://dev.gentoo.org/~ulm/pms/head/pms.html#section-12.3.15 may need updating to allow this. But it seems very valid to propose doing exactly that. I am not sure why it specifies e.g. "must ensure that GNU gzip" with heavy ties to implementations, when it doesn't specify such for
compression.
I'm guessing what you did was override/hook the unpack phase helper
function and divert it to 7zip instead. ;) It would be interesting to have actual hooks for that instead.
I stand by and reiterate my view that there is far too much of a cavalier attitude towards the matter in general out there including here in Gentoo. But not in particular here, it is everywhere where this is being discussed
at the moment.
Thanks for clarifying that, it wasn't clear to me when I read the
earlier e-mail.
Personally I think the long term solution is to identify critical code
bases that have a low bus factor before the bad actors do and make a concentrated community effort to help audit and maintain these code
bases.
On 4/3/24 11:30 AM, Eddie Chapman wrote:
Just to report I've been able to remove app-arch/xz-utils from my own
workstation, with 2412 packages installed and running kde. I'm going to
roll it out to my other gentoo systems which have a lot less stuff on them >> so am confident will be fine. It's not completely trivial but not as
difficult as I imagined it to be, certainly something an advance Gentoo
user could do if they wanted, with instructions. It does involve a
relatively small hack and functionality previously provided by xz-utils is >> replaced by app-arch/p7zip.
I'd just like to clarify my previous posts: what you're describing here
is neat and productive and valid to my eyes. Actually, I wish this had
been the topic of the *first* post in this thread. :)
[...]
On 24/04/01 08:40AM, orbea wrote:
On Mon, 1 Apr 2024 11:14:15 -0400
Kenton Groombridge <concord@gentoo.org> wrote:
On 24/03/31 12:13PM, Eddie Chapman wrote:
Eli Schwartz wrote:
On 3/29/24 11:07 PM, Eddie Chapman 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.
It suffices to downgrade to the version of xz before a social engineering attack by a malicious actor to gain
maintainership of the xz project.
Have you been linked to this yet? https://www.mail-archive.com/xz-devel@tukaani.org/msg00571.html
--
Eli Schwartz
Yes I saw that yesterday. It only increased my level of concern
about the project ten-fold rather than decreased it,
particularly because of "he has been helping a lot off-list and
is practically a co-maintainer already".
I think it's important to realize that this could have potentially happened to any number of various open source projects, not just xz-utils. Simply ripping it out and replacing it is not enough to
prevent these kinds of issues from happening in the future.
There is a major shifting of perspectives as a result of this
unfortunate compromise. Right now there are serious considerations
about banning (or otherwise auditing) binary blobs in some
projects. There are talks about banning the use of older build
systems like autotools in favor of ones more easily readable and auditable.
Talk about throwing the baby out with the bathwater...
Let's not shoot the messenger here. :)
I cited this specific example to highlight the shared intent behind
positive changes to auditing code not just in the program but also its
build system. I didn't mean to imply that this was a great solution.
Its fully possible to write autotools build systems which are simple
and easy to audit. Depending on what blob does it may be far from
trivial or advisable to get rid of it.
This attack as already has been clearly stated is social, not
technical. If xz-utils used meson or cmake instead it would of not
changed the situation.
Ultimately what is happening is a reflection on how we audit
critical system components and contributions made to them. Change
is not going to happen over night.
We saw a similar shift with OpenSSL's heartbleed, which
ultimately led to positive changes in code quality and improving
their vulnerability reporting process.
There is some good to come of this event, but it's important to
recognize what went wrong and how open source can improve as a
whole.
Eli Schwartz <eschwartz93@gmail.com> writes:
On 4/3/24 11:30 AM, Eddie Chapman wrote:Completely agreed. We just prefer shorter text and focusing on technical changes.
Just to report I've been able to remove app-arch/xz-utils from my own
workstation, with 2412 packages installed and running kde. I'm going to
roll it out to my other gentoo systems which have a lot less stuff on them >>> so am confident will be fine. It's not completely trivial but not as
difficult as I imagined it to be, certainly something an advance Gentoo
user could do if they wanted, with instructions. It does involve a
relatively small hack and functionality previously provided by xz-utils is >>> replaced by app-arch/p7zip.
I'd just like to clarify my previous posts: what you're describing here
is neat and productive and valid to my eyes. Actually, I wish this had
been the topic of the *first* post in this thread. :)
This sounds fun!
[...]thanks,
sam
That's not stupid at all, I'd been thinking exactly the same thing. I raised this whole issue during a discussion at FOSDEM 2019, where I admitted that I didn't check the code changes for packages I was bumping, knowing that few to none of the other people in the room did so either. Despite speaking up then, I still didn't do it because it's a heavy a burden and I'm not paid to do it. Now I'm thinking I really should, but I could really use some help. I'll raise
this idea at work. You could say that we specialise in these things. :)
Regards,
Chewi
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.
Eli Schwartz <eschwartz93@gmail.com> writes:
On 4/3/24 11:30 AM, Eddie Chapman wrote:
Just to report I've been able to remove app-arch/xz-utils from my own
workstation, with 2412 packages installed and running kde. I'm going
to roll it out to my other gentoo systems which have a lot less stuff
on them so am confident will be fine. It's not completely trivial but
not as difficult as I imagined it to be, certainly something an
advance Gentoo user could do if they wanted, with instructions. It
does involve a relatively small hack and functionality previously
provided by xz-utils is replaced by app-arch/p7zip.
I'd just like to clarify my previous posts: what you're describing here
is neat and productive and valid to my eyes. Actually, I wish this had
been the topic of the *first* post in this thread. :)
Completely agreed. We just prefer shorter text and focusing on technical changes.
This sounds fun!
[...]
thanks, sam
On 4/2/24 4:43 AM, Eddie Chapman wrote:
Well, they change one thing. It's hard for the security professionals at >>> work to deal with things when they are constantly having to respond to the >>> three-ring circus.
This is a complaint I hear very often from the people working at the heart >> of things. Stop making noise, shut up, we're overworked here and dealing
with your "complaints" just adds to our stress. I do understand and
sympathise with those feelings, believe me I do, I feel them myself in
other contexts.
But I hope you understand this is not finding things to nitpick about for
the sake of it. Does the Gentoo dev community want people on the "outside" >> to raise their concerns on their mailing list if those persons feel like
said community have got something very wrong, yes or no? If not then put a >> note on the mailing list page saying "please don't bother us, we're too
overworked, just post patches" or something to that effect.
I would be delighted to hear reasonable concerns. That's not what I'm referring to by "three-ring circus".
What does one have to do with the other? Why is it necessary to claim
that based on some sort of vibe check "there is too much compassion going >>> around in our communities, and this must mean that not enough effort is
being expended on the technical and cleanup aspects"?
I have not made such a claim, I've said I see lots of technical and
cleanup aspects. I've only stated the things that *are* happening versus
what is not happening at all (literally zilch) and which should be
happening, which is efforts towards a solution *not* involving the xz
utilities.
You say that as though a solution *not* involving the xz utilities is a reasonable takeaway from this scenario.
In order to demonstrate that such efforts deserve discussion at all, let alone efforts towards solving it, you first need to prove that:
- the xz utilities as shipped by Gentoo are something that should be
moved away from
- the xz utilities as released in 2022, when the backdoor author had
just as much access as you or I -- that is, none, aside for the right
to submit patches as suggestions -- are something that should be moved
away from
You have made no effort to justify either approach aside for claiming
that for unidentified reasons you believe this scenario demonstrates
that the "apparently innocent maintainer" now has an incentive to
"downplay the involvement of the bad actor".
If you had, I would be infinitely more interested in what you have to
say on the topic.
Also, if you had started with such.
Reading in between the lines, e.g. "trying desperately to salvage the
situation with xz-utils", I suspect you are trying to subtly suggest that >>> any second of time where gentoo hasn't yet removed xz-utils from gentoo as >>> a dead end is "cavalier".
Not quite, I've never advocated removing xz-utils at all, more than happy
for it to remain for whoever wants to use it. The only reason I started
this thread is I'm very unhappy about that fact that it is currently
impossible to NOT execute xz utilities on the Gentoo systems I'm
responsible for, without heavy customisation.
I'm also not demanding anything, let alone demanding anything instantly.
If I have please point out where.
Thank you for clarifying.
I am now just as convinced as I was yesterday, that you are trying to
subtly suggest it, but I'm newly convinced that you're also being
mendacious about it.
"It is cavalier for Gentoo to allow xz-utils as a package in the @system
set" is not meaningfully distinct from "it is cavalier for Gentoo to not
work to allow me to depclean xz-utils".
I understand that you are passionate about your suggestion to make
portage not validate distfile hashes.
That's incorrect, I've never suggested Portage should not validate
distfile hashes. The current behaviour is that validating distfile hashes
is something that can be disabled if a user wishes to, and I have no
problem with that at all, would not change a thing. I've said that, in
order to implement what I have suggested, a user would have to disable it, >> which is not ideal, but acceptable if the user controls the distfile
distribution. And I only suggested that in order to try and make the idea
more acceptable by not requiring impractical infra changes that would be
needed to generate uncompressed hashes for the Manifests).
In other words, you didn't care to find a robust solution, you just want something that you personally can use, and which requires being less
secure than using xz-utils.
But it's okay! It's not harassing portage devs with unreasonable
demands! Because it's *optional*, and by default people would just...
use xz-utils.
Even though the ***entire premise*** of changing anything here is that xz-utils as shipped by Gentoo is somehow dangerous and users have a
valid reason to want to avoid it entirely.
If you're going to recommend a solution for users who consider xz-utils
to be dangerous, then that solution should, you know, be better than
using xz-utils.
Not worse and less secure.
But I don't understand how you think
it's a solution to the xz-utils problem. For a wide variety of reasons,
but the simplest one is that your proposal has zero plan of action for
solving this at the community level and is entirely designed to allow
"lone wolf" users to use throwaway systems performing
security-sensitive actions (decompressing and hosting distfiles) in a
networked environment that has the xz-utils installed, to feed into other >>> security-sensitive systems (daily drivers etc.) that don't, but do have to >>> trust the artifacts produced by the former.
I'm not entirely clear what you're trying to say in this paragraph.
I am sarcastically saying that your proposal makes things worse and less secure for you, and doesn't even stop you from having to use xz-utils in
a context where a malicious xz-utils has the ability to inject attack
code into the uncompressed source code .tar files your proposal depends on.
But
what I will say is I've tried very hard in any suggestions I've made to
only suggest things which will NOT change any default behaviour or require >> big changes. The average user would not see any change from my revised
suggestions at all. I accepted after the first responses in this thread
that there was no appetite here to stop using xz utils. I then asked the
list about an idea I had just to see how palatable it might be. It was not >> supposed to be a concrete plan, I was seeking discussion about how it
might be possible in practise for someone to use Gentoo without
compression and decompression of distfiles. I tried to suggest a solution
that could be an optional feature people could enable if they wanted it.
But you should be proposing a change in default behavior! If it's not a change in default behavior then the change helps no one and there's no
point in making it.
If the change is good enough to make, it should be good enough to
propose its use by default, or at least as a recommended change people
should be encouraged to make while data is collected for rolling out the change as a switched default.
If you want a change that only applies to your personal system, Gentoo already has a solution: make an overlay that contains slightly modified versions of every ebuild in gentoo that has a SRC_URI mentioning *.xz files.
No changes to portage needed. Host your own tarballs on your own server
in SRC_URI. Validate them with checksums, even.
...
Or you could suggest patches to portage that improve the sandbox used to invoke decompression and archive extraction, so that it's "safe" to have
xz as a statically linked executable with no accompanying library
installed for the purpose of untrusted distfile extraction.
It's not being cavalier when zero portage developers responded by saying >>> "good idea I'll drop everything so I can get right on this and implement >>> it".
I'll just point out that I've never expected nor asked for anyone to
unquestionably accept anything I've said, let alone in the way you have
characterised there that I might have done. I do think that the oss/linux
community as a whole including Gentoo developers should seriously consider >> changing direction on this though. And I still think it is cavalier,
simply because by deciding on the current direction that is being taken,
very big (not an exaggeration) risks on behalf of all users are being
taken, while a much safer path for everyone is available but being
completely ignored. I do acknowledge, though, as I have said before, that >> this is far from easy in practise.
Sorry, but no.
When you say that the community's response is "cavalier" because the community is not accepting what you've said, you are inherently working
off the belief that the community's failure to accept what you've said
is because the community is *wrong* to question your suggestions.
If you think the community is wrong to question your suggestions then
you should be prepared to defend that point of view, particularly when
they are busy trying to coordinate a security response together with
security professionals from a wide variety of other distros, commercial vendors, OSS communities, etc. and have limited time to explain to
*hundreds* of people who each have their own badly thought out ideas
about what the FOSS community should do to solve the problem.
Your suggestion is only one such badly thought out idea. However, it
stands out from the rest because your suggestion has something that the
rest by and large lack: it has an accusation that distros, in this case Gentoo, are being cavalier about security.
This attitude of "Gentoo is being cavalier about security" is disproportionately worse than the average user interaction and, as has
been noted, is the reason why FOSS maintainers suffer burnout.
It has nothing to do with bringing up concerns. It has everything to do
with "if you don't agree with me you're being cavalier about MY security
as a Gentoo user".
Seriously. Please learn to bring up suggestions as suggestions, not as demands. It makes all the difference in the world.
Eli Schwartz wrote:
On 3/29/24 11:07 PM, Eddie Chapman 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.
It suffices to downgrade to the version of xz before a social
engineering attack by a malicious actor to gain maintainership of the xz project.
Have you been linked to this yet? https://www.mail-archive.com/xz-devel@tukaani.org/msg00571.html
--
Eli Schwartz
Yes I saw that yesterday. It only increased my level of concern about the project ten-fold rather than decreased it, particularly because of "he has been helping a lot off-list and is practically a co-maintainer already".
On 04/04/2024 15:24, Eddie Chapman wrote:
Since there appears to be some interest I'll put together a singleemail
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 :-).
Best wishes,
Eddie
[snip method]
On Sat, 06 Apr 2024, Eddie Chapman wrote:
[...] this is ridiculous and unnecessary :-).
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 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.
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 :-).
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
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.
[...]
- 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
[...]
- 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.
[...]
If you just want to verify signatures and manifests after sync,
qmanifest from portage-utils can help you do this.
Thanks,
Fabian
Eddie Chapman <eddie@ehuk.net> writes:
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.
==== 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/.
Hey,
I'll admit I didn't read everything, but I just want to point out you
may not have to edit ebuilds at all. If xz-utils is package.provided
portage should ignore the dependency without you removing the dep from an ebuild. Then you can utilize /etc/portage/patches to apply any patches and finally try using EXTRA_ECONF and MYMESONARGS to override configure
options via package.env.
-- juippis
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 16:49:45 |
| Calls: | 9,487 |
| Calls today: | 6 |
| Files: | 13,615 |
| Messages: | 6,121,086 |