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

-- 
Kenton Groombridge
Gentoo Linux Developer, SELinux Project