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 DB02B158041 for ; Mon, 1 Apr 2024 14:57:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 112AFE2A00; Mon, 1 Apr 2024 14:57:04 +0000 (UTC) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 C1EF7E29FA for ; Mon, 1 Apr 2024 14:57:03 +0000 (UTC) Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-dc74e33fe1bso3720896276.0 for ; Mon, 01 Apr 2024 07:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711983423; x=1712588223; darn=lists.gentoo.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/aJo/PUFifBuLwfBrK4VN7cxswOBzE/dJd+XLfWDxd4=; b=S6Um1/iJbUfAkWEsGw1bmW1HF36vPaJOslVgRX3g9JGUC4iJScJvJnyYRYWrFFOr51 cidEUSI9Drdfka/S/An2oTPYGaLbwtsxZ2WSmcxNV+9ic/8W2twPCkzB39jjzrBJLo4g 6BCCRwh+XRnzcdCdlHzMNQwSl1yBhQ3z8C59VxFpFIcnVH7Xjn07HbhmS+PS4IMbGX8+ j7GNQDz+GDlw0MYHXerMdynroplUQHulNl6PBSEq/rvKIEKRWhoxUE3+EHZATWvlBT+/ JEAQCBGxHITIcSJV6ptCdssJgCqDbM1cUdqeKu2P7u3XHjLTovxA2xku3r0exIskivQ4 Oq5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711983423; x=1712588223; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/aJo/PUFifBuLwfBrK4VN7cxswOBzE/dJd+XLfWDxd4=; b=sDoPdRUyKCjM+ZoChbIVco6PXKDdKzMpJt/7VM8gf91qveAMYAjcrYAVe97f5uE2DP lJZYhwWBDu5XUMQ/mEKq5vQZs15pgwBok0KskwgcWkvMbcsm+PhkEuqkhnHORukz6YNR FmRKg+FsFhpH0EmURMs9IJB4o7O69hl6dziK+yf3Mp9JXD/fkdwPSKUQu656u7sHo04d fjj7gnb/KVX+AFAQMxilw3eZYUiSXx3e+73ZZiblD/CEum812tJW/5Npl8Nw9TKmkple tLZfFpcJSL5rpLTAqMYAfFZMmgoBPXQZ++XL+QEZQyj1188k/KeZ34frRNlMPsRQzWYp VD1g== X-Gm-Message-State: AOJu0YxT1OIWtkitLuU4WecUlS6f6EJFXFuBSu4yrAJiG1+WIuumUWIV KFg8jjHVvn0gnkzSedOdsMimMbzLkKhoRaZQ7SuVbl6JEmKLs0y5IZ46BL6EeY5oH5q7uL0/82H WkihvMhJYQjScHbr0Z39LgJIzd3uAnaInuRs= X-Google-Smtp-Source: AGHT+IFo4RK0CSc0IcCB3ZF3RObHPvlJhw0x6ji432D02kFrsIStaVDMIwB5EESBOOKCPGIwyx9NE2CcNNZb2rq/lLE= X-Received: by 2002:a05:6902:56f:b0:dbe:9509:141c with SMTP id a15-20020a056902056f00b00dbe9509141cmr7944391ybt.30.1711983422886; Mon, 01 Apr 2024 07:57:02 -0700 (PDT) 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 References: In-Reply-To: From: Azamat Hackimov Date: Mon, 1 Apr 2024 17:56:51 +0300 Message-ID: Subject: Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 98f9b260-17df-438c-bb0b-d383973668a4 X-Archives-Hash: c343323ccb49e8a1021d3b8a77bb5c65 =D1=81=D0=B1, 30 =D0=BC=D0=B0=D1=80. 2024=E2=80=AF=D0=B3. =D0=B2 06:07, Edd= ie Chapman : > > 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 decompressio= n > 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. > > I see that many system package ebuilds unconditionally expect > app-arch/xz-utils to be installed simply to be able to decompress the > source archive in SRC_URI. So simply specifying -lzma on your system isn'= t > going to get rid of it. > > No one could have been expected to foresee what's happened with xz-utils, > but now that it's here, perhaps Gentoo (and other projects that do) shoul= d > consider not relying on a single decompression algorithm for source > archives, even just as an insurance against some other yet unknown > disaster with one algorithm or another in future? > > And yes I'm sure there will be individual packages that currently > absolutely need xz-utils installed during the build process, and one or > two that absolutely have to have it available at runtime, but those > bridges can be crossed as and when. > > Eddie > > There is no problem in the XZ/LZMA format itself as the reference algorithm is not compromised. It's all about trust between developers of application and developers of distribution. If you lost trust to xz-utils's developers, you may use alternatives like app-arch/pxz or app-arch/pixz. I don't see reasons why we should change format instead of changing a tool. -- >From Siberia with Love!