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 B1252158041 for ; Mon, 1 Apr 2024 16:01:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 890212BC022; Mon, 1 Apr 2024 16:01:49 +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) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1ECCC2BC019 for ; Mon, 1 Apr 2024 16:01:49 +0000 (UTC) Date: Mon, 1 Apr 2024 12:01:13 -0400 From: Kenton Groombridge To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo Message-ID: 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="njmq7tx4dsurhsko" Content-Disposition: inline In-Reply-To: <20240401084046.72639a7e@Akita> X-Archives-Salt: 319ac969-bc4f-4153-b63a-eb6274f9ae72 X-Archives-Hash: 62ae473fa88fa1418a32e93c91865dc0 --njmq7tx4dsurhsko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 24/04/01 08:40AM, orbea wrote: > On Mon, 1 Apr 2024 11:14:15 -0400 > Kenton Groombridge wrote: >=20 > > On 24/03/31 12:13PM, Eddie Chapman wrote: > > > Eli Schwartz wrote: =20 > > > > On 3/29/24 11:07 PM, Eddie Chapman wrote: > > > > =20 > > > >> 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. =20 > > > > > > > > > > > > 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 > > >=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 > >=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. > >=20 > > 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. >=20 > Talk about throwing the baby out with the bathwater... >=20 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. >=20 > 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. >=20 > > 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. > >=20 > > We saw a similar shift with OpenSSL's heartbleed, which ultimately led > > to positive changes in code quality and improving their vulnerability > > reporting process. > >=20 > > 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 >=20 >=20 --=20 Kenton Groombridge Gentoo Linux Developer, SELinux Project --njmq7tx4dsurhsko Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEP+u3AkfbrORB/inCFt7v5V9Ft54FAmYK2kVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNG RUJCNzAyNDdEQkFDRTQ0MUZFMjlDMjE2REVFRkU1NUY0NUI3OUUACgkQFt7v5V9F t55Qnw//Re64wRAQu0ao5ycUHRpPSL8gwLsN+CkxOy143x/8PGjoiqXS5kOUROlk +6ZTF/qgBRmRSNO1U+PM/M/cqCvAjkNRiB8k1ZO4lOYZx+7F06TPQD6DDIbCV60Y q3xUcqBknTraohlPxsJCK2xxb5pRf8BwfKPFnyItgcJbWbjUV7fsMRCakEFDHeYo 3IHZ1eEbL5A7hVGGTpg3rb1vmi7CUSAzGt52Qx6SvQ9cXIn1zAoI6WJqzhBn0EZq 5JmbON85Gml+gSCRKS50qbE9eMe28SlUQo9WdjRjdi5Rs5hWlvFRvcQUmJXwg81s hI0qkJCX+KB5pal0jxn4V+unDKizGYsXkFiWedYpongsomppNWD3JQIukp7k8m80 BCVIU1m0nOYFK5fcw5T5f16xny/LMMY9rRNTe056ZMVe1H04UgU/m5Y/wG9vCtY7 I7BtOqUO70j6xdScu9upGy6XgEb5UnBmvUUb5xMiB5UiugEdltOWfwPg2vWTMYjM wmtE42rXg4s1sQeGG7YKpT5a8pzigIyXR2yvIOydubi6MLIX3cUZbmmNM0XK5apE pZB9HjGOMufxB+G/vr8Ee/MzktpNT2kXCJS/aOAEKvHSDDYi3jaFEo772XXqNWja /QzZgW5zrtW4w3QMpvKsc1r7Jo9L+ij4XeG8i3I7/XkT/nYuoso= =ZyPE -----END PGP SIGNATURE----- --njmq7tx4dsurhsko--