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 90B35158041 for ; Mon, 1 Apr 2024 15:40:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 002E6E2A8E; Mon, 1 Apr 2024 15:40:49 +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 A7566E2A89 for ; Mon, 1 Apr 2024 15:40:48 +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 4V7Zwb4h46z9tVF for ; Mon, 1 Apr 2024 15:40:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1711986047; bh=npzR5lmT3LJLgG4K+FmYgLWI6WazNoay75SZ8d6+4hA=; h=Date:From:To:Subject:In-Reply-To:References:From; b=orHPpJIvxnzBW4sIxd8gQdrsv39mquAQ/ZJuP1chCrXmTfWMedSZxYemR9Nhf27WW 4KCfavPYbxRGbn+B0gHnTSbu8ggDlxjzrLGmUiR8kCDRxeLV4lyMY8dY7PvvAhegNb ddTFbxE+UobQzPPKPShnHA2YMA4YOgzij8GxQgOw= X-Riseup-User-ID: 89F2B59633AA9FA8484DF247972C69B82C960051CC7F04FAA0A3A24203DC84A9 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews01-sea.riseup.net (Postfix) with ESMTPSA id 4V7Zwb2dtZzJqbV for ; Mon, 1 Apr 2024 15:40:47 +0000 (UTC) Date: Mon, 1 Apr 2024 08:40:46 -0700 From: orbea To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo Message-ID: <20240401084046.72639a7e@Akita> In-Reply-To: <4pnr6chy4rgtpp6o2yrmdihqfalj2tjhlooscbk4k4de3hbcf3@72c2xd7bmmsn> References: <42575b278b15f667e08084b83de0d7af.squirrel@ukinbox.ecrypt.net> <4pnr6chy4rgtpp6o2yrmdihqfalj2tjhlooscbk4k4de3hbcf3@72c2xd7bmmsn> 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: fcc54289-4e9e-4cd0-b587-59205bdc8a73 X-Archives-Hash: 82aea8aa3e99f4610cdc1eb0f0427702 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... 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. >