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 88231158041 for ; Mon, 1 Apr 2024 15:14:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DD738E2A4F; Mon, 1 Apr 2024 15:14:20 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 951EAE2A43 for ; Mon, 1 Apr 2024 15:14:20 +0000 (UTC) Date: Mon, 1 Apr 2024 11:14:15 -0400 From: Kenton Groombridge To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo Message-ID: <4pnr6chy4rgtpp6o2yrmdihqfalj2tjhlooscbk4k4de3hbcf3@72c2xd7bmmsn> References: <42575b278b15f667e08084b83de0d7af.squirrel@ukinbox.ecrypt.net> 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mbxz3ghyt4isynow" Content-Disposition: inline In-Reply-To: <42575b278b15f667e08084b83de0d7af.squirrel@ukinbox.ecrypt.net> X-Archives-Salt: 6eb2196b-a6d9-44b2-9da9-d8e339596e2e X-Archives-Hash: 3482a9c97ce8f3e19e2de0b76275659e --mbxz3ghyt4isynow Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 suitab= le > >> 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 personal= ly > >> 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 > > >=20 > 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". >=20 >=20 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. 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. --=20 Kenton Groombridge Gentoo Linux Developer, SELinux Project --mbxz3ghyt4isynow Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEP+u3AkfbrORB/inCFt7v5V9Ft54FAmYKz0RfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNG RUJCNzAyNDdEQkFDRTQ0MUZFMjlDMjE2REVFRkU1NUY0NUI3OUUACgkQFt7v5V9F t57XVg//Rfhk3wg0j7cz9DH4KmBsmQsembLh0hMdos9C0z1wZvnFMYUTR+mieaJ2 Mu8IFTdkJhI91+JQQ/94EUoKtELPVoQC5BTFcWl/9JpaREaqg5joChd1C42pFf9Z ranKAekM8P9e9qkzax/w9VmouUNTWycnHIPAX3K1c+XH/E4eSKna+TEIORpLemcf j3cL8NZNngpT+og0nikBcra/U9guvoPdaKhgPwHxPSUJ805QEUiJ2/8abmLyS0sk 6/6IQxgcLZtVVZ9lXZ572dEZ4Om2N4yRBJRrHMxIg1nMbeza2KMwBJOK+IOlyXUZ 00cH0UxMr1mie//1HaCxOQzl/AIvNGqLX4TSpWymI62bgA4gSbJcBxrZ51QQTDDv op5gfuq6GXWb9vFyTr93mNpY+0PPoSXpCmsaymZSgWKujK9nENGa2+WMbh9agI8X Y75WoG57OO9J2jeO8lK8gd3RAxSskhE/YHo5xhAOTQrRXTUdbQWuKWwhS/hxtjHv WBppTsuBOtjHhdWq06ltKsBdW3rn4H5z0Nj4i+Yvs7Qcqrplp91i6JRRxntpdTfo eXfbZoEl6bvMzoo8T7PbL4fGfUxS1x998P3UnrFi7t34XqFiTuUwEupBHslZ5i34 POsA8g+ZJkma4OdAIA4OClJ7CPI0JJzFNM8T6GKvIjiiuwMrRgE= =a6BN -----END PGP SIGNATURE----- --mbxz3ghyt4isynow--