Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

[Kenton Groombridge <concord@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2573 bytes --]

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. 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.

-- 
Kenton Groombridge
Gentoo Linux Developer, SELinux Project

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]