From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id cA/VN/YxD2YJEwEA62LTzQ:P1 (envelope-from ) for ; Fri, 05 Apr 2024 01:04:23 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id cA/VN/YxD2YJEwEA62LTzQ (envelope-from ) for ; Fri, 05 Apr 2024 01:04:23 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=elephly.net header.s=zoho header.b="Wzh5/i3s"; arc=pass ("zohomail.com:s=zohoarc:i=1"); 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=2; s=key1; d=yhetil.org; t=1712271862; a=rsa-sha256; cv=pass; b=pzqwEEvIEvVKMGA3VBg0f1ZeryYcOba8tpInv5xVnpV469aoNT1CoSvYvXbmiCv9yZqTVz n+jr8cXr9ytcTdfxBq07T5fULXPKugC6ZwiSsFg19r79pXY35zJkTVAVqTdVq+0hkPJyRs ZxYmWMVsWvSJCdPIzCPj5IAIxbTSfryUmTDynNL8dyWDmXtMbTgXjQa9BmVFPclrcsni0f qug+M4wfnCAIskBCi0pwz5P0JOte5NDUv+TMXt5XIqaLILVLNJit4uFm7rGjgRzNnRDPzw 2UvykMzWSVV/36ccb6BdD4+DeeUy2gwjho000ILTEtuyXWwwKm2msv2t0m8D1A== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=pass header.d=elephly.net header.s=zoho header.b="Wzh5/i3s"; arc=pass ("zohomail.com:s=zohoarc:i=1"); 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=2; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1712271862; 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:dkim-signature; bh=/gRv/gOiFA+0ietIvduo4/CFGfXmcMtGXLkPuH04e9o=; b=Xy8wMEXLDPDBKzh4CQO/eqoPZKouq+hls6Rrkp72f4n2zK+E73O5RVM98coA85lXAGYtef 2RFkIf5t+zmEwjpZ03qO3a9hmqgBkahW5y8ldaToKYH2vT5Hf4Yl3FogRpQTVQBK3KzYdf XvMS01CusSon4y47p+OeOFIpZdqrsqd5Z9aKTOj1qtTLF4tWxdowA8H+SexW1EWbmouSrk QHYCCL0EjOq6aYCeX0VA0mARrTggetXoDbCyD0iqHAq41rj7Di2fKCcQJlRlHCTajbdPmH M5OOajnTrAvlmw+dSz9gy0sHIIJCh4oDJFcOKZ4Qg5NxlAshhPN/bJFLxfQ67Q== 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 1A5536C0BD for ; Fri, 5 Apr 2024 01:04:22 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rsW7R-0001Lr-Em; Thu, 04 Apr 2024 19:03:41 -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 1rsW7O-0001LJ-Uo; Thu, 04 Apr 2024 19:03:39 -0400 Received: from sender4-of-o51.zoho.com ([136.143.188.51]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rsW7M-0006vw-LT; Thu, 04 Apr 2024 19:03:38 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1712271806; cv=none; d=zohomail.com; s=zohoarc; b=SaXWMnvQgAQS1X7AAQF6IGu8sDU0ODThVJcWzI2nXEXWaOgMyI9u/x7PNPDX5VKbxL9+gtmY+QY+6awuyvUOJkxw8+49P4LgphQOgC3svtAXjcGlqD+tBywqJW2xW2C3qofEQ5M48Otr0gJJ7N1c1IBA3G5fWlKp1tTJClP2q8g= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1712271806; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=/gRv/gOiFA+0ietIvduo4/CFGfXmcMtGXLkPuH04e9o=; b=NJaol0xsp6gTkN2A7E7s0LSAfTFDg4zEw+TdiYqEHQfX0s6js2jRPM1QzUIyyhrT7geZVYGHcEeSfBUr8qbdoE7NlOmw3Y+RVbVQyJbPO2E+l4EhBc6gFLjz9nWDj1WSs3jCfLSsukiB/LoGEMgG3xsBQh6ciJMRD62P1jarZyc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=elephly.net; spf=pass smtp.mailfrom=rekado@elephly.net; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1712271806; s=zoho; d=elephly.net; i=rekado@elephly.net; h=From:From:To:To:Cc:Cc:Subject:Subject:In-Reply-To:References:Date:Date:Message-ID:MIME-Version:Content-Type:Message-Id:Reply-To; bh=/gRv/gOiFA+0ietIvduo4/CFGfXmcMtGXLkPuH04e9o=; b=Wzh5/i3sdTXbjsVEZqWxCf7pBFKmTbxUw8/LCVNpKNUKr8iHccHDclTxqUjnT9cq ozcIoIAYv4MqTP81hErdcbTiK4ClDp2EofSO3D9YddKKPonJ064FFGdYMB1EnTBZ0MG s0VnbBxci41J5EDNjA4sImlKYe0o8zKa+yiEVPiA= Received: by mx.zohomail.com with SMTPS id 1712271803661511.9150572975442; Thu, 4 Apr 2024 16:03:23 -0700 (PDT) From: Ricardo Wurmus To: Giovanni Biscuolo Cc: Guix Devel , guix-security@gnu.org, Felix Lechner , Ryan Prior Subject: Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils) In-Reply-To: <8734s1mn5p.fsf@xelera.eu> (Giovanni Biscuolo's message of "Thu, 04 Apr 2024 12:34:42 +0200") References: <87ttkon4c4.fsf@protonmail.com> <8734s1mn5p.fsf@xelera.eu> User-Agent: mu4e 1.12.2; emacs 29.3 Date: Fri, 05 Apr 2024 01:03:19 +0200 Message-ID: <87jzlck9xk.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.188.51; envelope-from=rekado@elephly.net; helo=sender4-of-o51.zoho.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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-Spam-Score: -10.37 X-Migadu-Queue-Id: 1A5536C0BD X-Migadu-Spam-Score: -10.37 X-Migadu-Scanner: mx10.migadu.com X-TUID: HujjSgIRG6sp [mu4e must have changed the key bindings for replies, so here is my mail again, this time as a wide reply.] Giovanni Biscuolo writes: > So AFAIU using a fixed "autoreconf -fi" should mitigate the risks of > tampered .m4 macros (and other possibly tampered build configuration > script)? > > IMHO "ignoring" (deleting) pre-built build scripts in Guix > build-system(s) should be considered... or is /already/ so? The gnu-build-system has a bootstrap phase, but it only does something when a configure script does not already exist. We sometimes force it to bootstrap the build system when we patch configure.ac. In previous discussions there were no big objections to always bootstrapping the build system files from autoconf/automake sources. This particular backdoor relied on a number of obfuscations: - binary test data. Nobody ever looks at binaries. - incomprehensibility of autotools output. This one is fundamentally a social problem and easily extends to other complex build systems. In the xz case, the instructions for assembling the shell snippets to inject the backdoor could hide in plain sight, just because configure scripts are expected to be near incomprehensible. They contain no comments, are filled to the brim with portable (lowest common denominator) shell magic, and contain bizarrely named variables. Not using generated output is a good idea anyway and removes the requirement to trust that the release tarballs are faithful derivations from the autotools sources, but given the bland complexity of build system code (whether that's recursive Makefiles, CMake cruft, or the infamous gorilla spit[1] of autotools) I don't see a good way out. [1] https://www.gnu.org/software/autoconf/manual/autoconf-2.65/autoconf.html#History > Given the above observation that < to peer review a tarball prepared in this manner>>, I strongly doubt that > a possible Makefile tampering _in_the_release_tarball_ is easy to peer > review; I'd ask: is it feaseable such an "automated analysis" (see > above) in a dedicated build-system phase? I don't think it's feasible. Since Guix isn't a regular user (the target audience of configure scripts) it has no business depending on generated configure scripts. It should build these from source. > In other words: what if the backdoor was injected directly in the source > code of the *official* release tarball signed with a valid GPG signature > (and obviously with a valid sha256 hash)? A malicious maintainer can sign bad release tarballs. A malicious contributor can push signed commits that contain backdoors in code. > Do upstream developer communities peer review release tarballs or they > "just" peer review the code in the official DVCS? Most do neither. I'd guess that virtually *nobody* reviews tarballs beyond automated tests (like what the GNU maintainers' GNUmakefile / maint.mk does when preparing a release). > Also, in (info "(guix) origin Reference") I see that Guix packages can have a > list of uri(s) for the origin of source code, see xz as an example [7]: > are they intended to be multiple independent sources to be compared in > order to prevent possible tampering or are they "just" alternatives to > be used if the first listed uri is unavailable? They are alternative URLs, much like what the mirror:// URLs do. > If the case is the first, a solution would be to specify multiple > independent release tarballs for each package, so that it would be > harder to copromise two release sources, but that is not something under > Guix control. We have hashes for this purpose. A tarball that was modified since the package definition has been published would have a different hash. This is not a statement about tampering, but only says that our expectations (from the time of packaging) have not been met. > All in all: should we really avoid the "pragmatically impossible to be > peer reviewed" release tarballs? Yes. -- Ricardo