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

[orbea <orbea@riseup.net>]

On Mon, 1 Apr 2024 12:01:13 -0400
Kenton Groombridge <concord@gentoo.org> wrote:

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

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.

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