On Mon, 1 Apr 2024 12:01:13 -0400 Kenton Groombridge <conc...@gentoo.org> wrote:
> On 24/04/01 08:40AM, orbea wrote: > > On Mon, 1 Apr 2024 11:14:15 -0400 > > Kenton Groombridge <conc...@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. > > > > >
