From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9FA86158041 for ; Mon, 1 Apr 2024 16:21:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id ED340E2A3F; Mon, 1 Apr 2024 16:21:26 +0000 (UTC) Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AF2FFE2A39 for ; Mon, 1 Apr 2024 16:21:26 +0000 (UTC) Received: from fews01-sea.riseup.net (fews01-sea-pn.riseup.net [10.0.1.109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx0.riseup.net (Postfix) with ESMTPS id 4V7bqT6gYnz9sch for ; Mon, 1 Apr 2024 16:21:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1711988486; bh=s2HVTcwBqUU8GfA38MqxE2VU/2ble6gEEUgw3Z3xE/0=; h=Date:From:To:Subject:In-Reply-To:References:From; b=iZUnm0AdrVK2ZQbvhDASaA2bWkmXMmpKOl5oBPJnebxLNyeIYqmQLY3GE3xo8H2pH NUgg/MRlnIn8FfPhKyp2uINUGu+m4ld7GWM8PHvJ6DNHPwCUAfhYeszSaAwTrak1TO FWxiPtOBLcueBz9GJtiZcZVr/3Xfn4Siou3wSOyg= X-Riseup-User-ID: 1D56214189C997C1215093F2998F7E4C518CE65D3CD1170ACA4E40136DB3F7DF Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews01-sea.riseup.net (Postfix) with ESMTPSA id 4V7bqG4dgXzJmqP for ; Mon, 1 Apr 2024 16:21:14 +0000 (UTC) Date: Mon, 1 Apr 2024 09:21:13 -0700 From: orbea To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo Message-ID: <20240401092113.7018fbec@Akita> In-Reply-To: References: <42575b278b15f667e08084b83de0d7af.squirrel@ukinbox.ecrypt.net> <4pnr6chy4rgtpp6o2yrmdihqfalj2tjhlooscbk4k4de3hbcf3@72c2xd7bmmsn> <20240401084046.72639a7e@Akita> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 0acaf82b-5d7e-4fae-b79c-774cbe43956a X-Archives-Hash: 435d4fee74cc3b6863eedc7ac6140144 On Mon, 1 Apr 2024 12:01:13 -0400 Kenton Groombridge wrote: > On 24/04/01 08:40AM, orbea wrote: > > On Mon, 1 Apr 2024 11:14:15 -0400 > > Kenton Groombridge 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. > > > > >