From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id IAduAWorGmZydAEAe85BDQ:P1 (envelope-from ) for ; Sat, 13 Apr 2024 08:51:22 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id IAduAWorGmZydAEAe85BDQ (envelope-from ) for ; Sat, 13 Apr 2024 08:51:22 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1712991081; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=ptl3nowwrH0Kp65DmJNBdCxexZBtoqCidPtS/lVmNz8=; b=uJ3isHyNwQHMhyIBavVeBdyBvtzCDRI+IAEf6TsdMW2+5scJAomCQQXi6X+wuWtaY467EC gpMsXHeHbAG7GmYF137GNgOU5mfFw86Xh6Nhy6/PD4MjXJjGwm5l6OIo7GPPuoNsYtMO8u qnMoZR/2PDqQDtqS9CZ03Ho/bu4uIkcTOtG2PAm8cJdkRwuhjAzCMiHY0s65htW001tBkc 1Rg403kUqO6JkTvcaqFX0z5jTc47koB9xNE9QZcoTVGfhzVpaCUh3sc8GbMsKeNwcuBWkd W4ULeIPE2a6kI1fcjOpJoD1mvEJ5MvpH1RFcaBJGcRwPMmjkdrMUxUu3pJgxIw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1712991081; a=rsa-sha256; cv=none; b=kMyCnWBIgCyjYRzDFpY23LC3jpU/g5JBhVtGPeMRMkeK5f+DLdLbh8ZbLOUTRjsmamHIwm 12klDy0un8Zo2w0Tw3Hr8TjSlbIE9Jcnpz1C+GlB8ThZHKOwztXcRVpmKewCGs/cRuQB85 YFc5qoPspVdsqyMJ7GcMmEaWFEgMDaA5vmEIckeYbtJlJkOV3nvPfFRXpYWqKC+A+Gv1Fj 95Ms8drFaHycHsyt23JdXr90znkAPY5eLkvsBX0w9y/HsSAwfodcPhX29pSPWkaQ61IG+V ZsXWsjfTEx196LFs4dEpNqj2rBQDdMM6PhHwL5XCQ2D4PCDVQc8X6/0zNyeOog== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 82DC9E8D1 for ; Sat, 13 Apr 2024 08:51:21 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rvXDo-0002B9-PF; Sat, 13 Apr 2024 02:50:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rvXDm-0002Av-2u for guix-devel@gnu.org; Sat, 13 Apr 2024 02:50:42 -0400 Received: from ns13.heimat.it ([46.4.214.66]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rvXDg-0001mA-0N; Sat, 13 Apr 2024 02:50:41 -0400 Received: from localhost (ip6-localhost [127.0.0.1]) by ns13.heimat.it (Postfix) with ESMTP id 2F2853007E0; Sat, 13 Apr 2024 06:50:31 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at ns13.heimat.it Received: from ns13.heimat.it ([127.0.0.1]) by localhost (ns13.heimat.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g24_3ERNj-Kk; Sat, 13 Apr 2024 06:50:29 +0000 (UTC) Received: from bourrache.mug.xelera.it (unknown [93.56.171.217]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ns13.heimat.it (Postfix) with ESMTPSA id 415FC30022D; Sat, 13 Apr 2024 06:50:29 +0000 (UTC) Received: from roquette.mug.biscuolo.net (roquette [10.38.2.14]) by bourrache.mug.xelera.it (Postfix) with SMTP id C49FB30D9B90; Sat, 13 Apr 2024 08:50:28 +0200 (CEST) Received: (nullmailer pid 1808 invoked by uid 1000); Sat, 13 Apr 2024 06:50:28 -0000 From: Giovanni Biscuolo To: Andreas Enge , Ekaitz Zarraga Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , Attila Lendvai , Guix Devel Subject: Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils) In-Reply-To: Organization: Xelera.eu References: <87ttkon4c4.fsf@protonmail.com> <8734s1mn5p.fsf@xelera.eu> <87zfu9ku4l.fsf@xelera.eu> <6e743725-26f0-669c-b088-e56c850110c8@elenq.tech> <87wmp5l3r3.fsf@gnu.org> <8076578a-bebd-0f26-6d39-f634ded290ce@elenq.tech> Date: Sat, 13 Apr 2024 08:50:27 +0200 Message-ID: <87y19hiwng.fsf@xelera.eu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=46.4.214.66; envelope-from=g@xelera.eu; helo=ns13.heimat.it X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.48 X-Migadu-Scanner: mx11.migadu.com X-Spam-Score: -6.48 X-Migadu-Queue-Id: 82DC9E8D1 X-TUID: reiNA2q52cR0 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, general reminder: please remember the specific scope of this (sub)thread =2D-8<---------------cut here---------------start------------->8--- Please consider that this (sub)thread is _not_ specific to xz-utils but to the specific attack vector (matrix?) used to inject a backdoor in a binary during a build phase, in a _very_ stealthy way. Also, since Guix _is_ downstream, I'd like this (sub)thread to concentrate on what *Guix* can/should do to strenghten the build process /independently/ of what upstreams (or other distributions) can/should do. =2D-8<---------------cut here---------------end--------------->8--- (https://yhetil.org/guix/8734s1mn5p.fsf@xelera.eu/) ...and if needed read that message again to understand the context, please. Andreas Enge writes: > Am Thu, Apr 11, 2024 at 02:56:24PM +0200 schrieb Ekaitz Zarraga: >> I think it's just better to >> obtain the exact same code that is easy to find > > The exact same code as what? Of what is contained in the official tool used by upstream to track their code, that is the one and _only_ that is /pragmatically/ open to scrutiny by other upstream and _downstream_ contributors. > Actually I often wonder when looking for a project and end up with a > Github repository how I could distinguish the "original" from its > clones in a VCS. Actually it's a little bit of "intelligence work" but it's something that usually downstream should really do: have a reasonable level of trust that the origin is really the upstream one. But here we are /brainstormig/ about the very issue that led to the backdoor injection, and that issue is how to avoid "backdoor injections via build subversion exploiting semi-binary seeds in release tarballs". (see the scope above) > With the signature by the known (this may also be a wrong assumption, > admittedly) maintainer there is at least some form of assurance of > origin. We should definitely drop the idea of "trust by autority" as a sufficient requisite for verifiability, that is one assumption for reproducible builds. The XZ backdoor injection absolutely demonstrates that one and just one _co-maintainer_ was able to hide a trojan in the _signed_ release tarball and the payload in the git archive (as very obfuscated bynary), so it was _the origin_ that was "infected". It's NOT important _who_ injected the backdoor (and in _was_ upstream), but _how_. In other words, we need a _pragmatic_ way (possibly with helping tools) to "challenge the upstream authority" :-) >> and everybody is reading. > > This is a steep claim! I agree that nobody reads generated files in > a release tarball, but I am not sure how many other files are actually > read. Let's say that at least /someone/ should be _able_ to read the files, but in the attack we are considering /no one/ is _pragmatically_ able to read the (auto)generated semi-binary seeds in the release tarballs. Security is a complex system, especially when considering the entire supply chain: let's focus on this _specific_ weakness of the supply chain. :-) Ciao! Gio' =2D-=20 Giovanni Biscuolo Xelera IT Infrastructures --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmYaKzQMHGdAeGVsZXJh LmV1AAoJENN9DqfOzDkSJy8P/jy08a7qB251ak6eHSsB4lz+X4CJSkvfZgiQwKJJ vi/idn+k9deeCzBA7t+BbqyQoJSm2DXytzoz8L1N2b+C0WwVN2RtRFdIxFkDsjDa 1mrKQyyyZ8ySmLLWBIYR8p7ldM9afVD3wm6croMm1F+bw33dBe3FY3UYA68VHTQd 3eERhymVqBPhbNqgumtQ2AS7hJtdlafHxOTia+gIGandF9QT0LIo5Z5XhIWAdcHr X0MQXZqDq741WmI+WDAfBD7svEVYHD7PPEd27fQojdhPYeaoXov4fWPsV/MhWrQe 9eJtOQBRBD6ClwwdEjNIawDHxTTtTxHNr7ODtjKxOSZg2zxpQ0tsXcUKocLONXSC 0hcVH9Jt19seVxbkNG0IwLyynuX6kHDuk/ge9LuDupDB88VitWHznsUP5U/se6/D Tf+H6gyZEAkfoBj84/BqRiJrgMa9784DaTF4NvssLrdBUgqKi2/YIlJkGQn8sVzX L/PVQNEth1ZjJhbU2LHix1TaIJlX1VP4jTQKkpY3bdWUF6maUCJLm6at1goHxztA GyroRfnevMyynbjpBl5M2+Vep3YcaLXLc/r/i3adt53rhmuDdahiOTfrSI548f4V m1aAm6kzrDx6ZzBOSFLjGU8tKFKUv/BEyJ4FBZQx/o3Dqsa2uGyiVl/opMMBLCIS J+sv =1UoJ -----END PGP SIGNATURE----- --=-=-=--