From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 6LPmNlpN3GG/RAEAgWs5BA (envelope-from ) for ; Mon, 10 Jan 2022 16:14:34 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id kLFcNFpN3GHsbgEA9RJhRA (envelope-from ) for ; Mon, 10 Jan 2022 16:14:34 +0100 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 5160624C2C for ; Mon, 10 Jan 2022 16:14:34 +0100 (CET) Received: from localhost ([::1]:36330 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n6wNV-00066r-7K for larch@yhetil.org; Mon, 10 Jan 2022 10:14:33 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58260) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6w3e-0006u5-MZ for guix-patches@gnu.org; Mon, 10 Jan 2022 09:54:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:59150) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n6w3e-0002Yy-DQ for guix-patches@gnu.org; Mon, 10 Jan 2022 09:54:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n6w3e-0007yS-9w for guix-patches@gnu.org; Mon, 10 Jan 2022 09:54:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#50814] [PATCH] guix: git-authenticate: Also authenticate the channel intro commit. Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Mon, 10 Jan 2022 14:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50814 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Attila Lendvai Cc: 50814@debbugs.gnu.org Received: via spool by 50814-submit@debbugs.gnu.org id=B50814.164182643330635 (code B ref 50814); Mon, 10 Jan 2022 14:54:02 +0000 Received: (at 50814) by debbugs.gnu.org; 10 Jan 2022 14:53:53 +0000 Received: from localhost ([127.0.0.1]:52053 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6w3V-0007y3-3V for submit@debbugs.gnu.org; Mon, 10 Jan 2022 09:53:53 -0500 Received: from hera.aquilenet.fr ([185.233.100.1]:44954) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n6w3P-0007xe-QP for 50814@debbugs.gnu.org; Mon, 10 Jan 2022 09:53:51 -0500 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 1BBC72CB; Mon, 10 Jan 2022 15:53:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aThzKInTF4O; Mon, 10 Jan 2022 15:53:39 +0100 (CET) Received: from ribbon (91-160-117-201.subs.proxad.net [91.160.117.201]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 6EBCB251; Mon, 10 Jan 2022 15:53:39 +0100 (CET) From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20211018155734.5175-1-attila@lendvai.name> <20211018155734.5175-5-attila@lendvai.name> Date: Mon, 10 Jan 2022 15:53:38 +0100 In-Reply-To: <20211018155734.5175-5-attila@lendvai.name> (Attila Lendvai's message of "Mon, 18 Oct 2021 17:57:34 +0200") Message-ID: <87sftvy74d.fsf_-_@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / X-Rspamd-Server: hera X-Rspamd-Queue-Id: 1BBC72CB X-Spamd-Result: default: False [-0.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1641827674; 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: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=7Vh3VgBweU+NcrtA74/j9fckyWqrA7OB6oC8CkB2cBA=; b=DhPKzxL1OGBNkVUPBVQllzQEFQcx9RSc4jQAneR3ylX+oHTx/DDGDSsD1p/ey+qpCJxdqB U6zZc9ill4yageqkLy9O21wDTTmoupmmwA31iSZU0nMwMFRwt5x2CbVlANVVdH5BF+tqL5 8FOOuWc9xNW4rFqnt5eUB+dImRA8QpjyW0UtA5Sn0OwdNVGTTO7fY36awtZw7Iel8NoXPw wnFRvG9lhbhFggxxXoklYDob68XkY7ZrvM/CFm1RfZGzr1o2e7/KfABS1adMuzTRG37b+j L8F0xewDBHSp/J51SHbocbYiUhSPEJLaxkvj0mWV9kte7WDUoPTgA0mJK+tejw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641827674; a=rsa-sha256; cv=none; b=nLsaKRoG/wxLZqtKLEBPyEVClt5oOHZRFSufu+QmWsEQ0TneqYSgGSrP2hYtOxh08PbH8b puxlL9jYS0+N9DSQzPdqL+Hxue+W9suwIOn0SP1QbJrh/Ba9K7xCIatETar/qh1EotF7Nc z6GhovjqkmRM+Lj3Q51/rjJEsWHpJ6uHG5vkGm5HrYuSyGjumMsu+KcfbmG9FIBRvsK/Ee Myt1kc+h1wwZc4jZWjoLhXXi8yZTHQ1gbZnVSwY2FfWBFNDU4El0dBln1B1JMa44zBWxLh May2V7agCUFMsAgQjKXwJHZzxIJDusSpfBewSBD2+9CvNVQEyqgt40tbgSrfyg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.61 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 5160624C2C X-Spam-Score: -3.61 X-Migadu-Scanner: scn1.migadu.com X-TUID: SGpnpVD2q/k3 Hi Attila, Sorry for dropping the ball. On the private guix-security mailing list, I just sent an analysis showing why the bug reported there was, AFAICS, not a bug; however, the test here is different and seems to be poised to expose a different problem. Attila Lendvai skribis: > This test used to fail before a recent fix to authenticate-repository. > > * tests/git-authenticate.scm: New test "signed commits, .guix-authorizati= ons, > channel-introduction". I won=E2=80=99t comment on the whole test for now, because it=E2=80=99s too= complex, but here=E2=80=99s what I noticed: [...] > + (checkout "main" orphan) > + (add "noise0") > + (add ".guix-authorizations" > + ,(object->string > + `(authorizations > + (version 0) > + ((,(key-fingerprint key1) (name "Alice")) > + ;; Notice that key2 is not authorized at this poin= t. > + (,(key-fingerprint key3) (name "Charlie")))))) > + (commit "commit 0" (signer ,(key-fingerprint key3))) > + (add "noise1") > + (commit "commit 1" (signer ,(key-fingerprint key1))) > + (add "noise2") > + (commit "commit 2" (signer ,(key-fingerprint key1)))) > + (with-repository dir repo > + (let* ((commit-0 (find-commit repo "commit 0")) > + (check-from > + (lambda* (commit #:key (should-fail? #false) (key key1) > + (historical-authorizations > + ;; Let's mark key3 to be trusted > + ;; unconditionally, so that it autho= rizes > + ;; commit 0. > + (list (key-fingerprint-vector key3))= )) This is exercising support for =E2=80=9Chistorical authorizations=E2=80=9D,= which works slightly differently than the regular =E2=80=98.guix-authorizations=E2=80= =99-process used by =E2=80=98guix pull=E2=80=99 & co. > + (set! commit (find-commit repo commit)) Mutation is making it harder for me to understand what the test does. > + (with-git-repository dir > + ;; Drop the faulty commit 3 > + `((reset ,(oid->string (commit-id (find-commit repo "com= mit 2")))) > + (add "noise 4") > + (add ".guix-authorizations" > + ,(object->string > + ;; Remove key3, add key2. > + `(authorizations > + (version 0) > + ((,(key-fingerprint key1) (name "Alice")) > + (,(key-fingerprint key2) (name "Bob")))))) > + (commit "commit 4" (signer ,(key-fingerprint key2)))) Due to =E2=80=98reset=E2=80=99 here, the intro commit that =E2=80=98check-f= rom=E2=80=99 passes to =E2=80=98authenticate-repository=E2=80=99 is no longer the right one (IIUC). > + ;; This should fail because even though commit 4 adds key2= to > + ;; .guix-authorizations, but commit 1 was created prior to= that, > + ;; therefore it is not authorized. > + (check-from "commit 1" #:should-fail? #true) > + ;; This should pass, because it's a valid channel intro at= commit 4 > + (check-from "commit 4" #:key key2)) > + (with-git-repository dir > + `((add "noise 5") > + (commit "commit 5" (signer ,(key-fingerprint key2)))) > + ;; It is not very intuitive why commit 1 and 2 should be t= rusted > + ;; at this point: commit 4 has previously been used as a c= hannel > + ;; intro, thus it got marked as trusted in the ~/.cache/. > + ;; Because commit 1 and 2 are among its parents, it should= also > + ;; be trusted at this point because of the cache. Note th= at > + ;; it's debatable whether this semantics is a good idea, b= ut > + ;; this is how git-authenticate is and has been implemente= d for > + ;; a while (modulo failing to update the cache in the past= when > + ;; taking certain code paths). Any commit in the closure of one of those listed in ~/.cache/guix/authentication is considered authentic. So, if you arrange to populate that file with IDs of commits that were not authenticated, then yes, you=E2=80=99ll find that =E2=80=98authenticate= -repository=E2=80=99 reports surprising things. But that=E2=80=99s because fundamentally, we ca= nnot protect the user from self-inflicted attacks. To summarize, I do not see a bug here, but I=E2=80=99m also not sure what t= he test was trying to demonstrate. Could you boil it down? (Keep in mind that it takes a lot of time to merely review and under the test and claim.) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On guix-security (in your Dec. 22, 2021, message), you provided a different test case, showing that the introductory commit=E2=80=99s signatu= re is not verified when =E2=80=98authenticate-repository=E2=80=99 is asked to aut= henticate an empty commit range (introductory commit =3D tip of the branch). This is due to the (null? commit) condition in =E2=80=98authenticate-repository=E2= =80=99: ;; When COMMITS is empty, it's because END-COMMIT is in the closure of ;; START-COMMIT and/or AUTHENTICATED-COMMITS, in which case it's known to ;; be authentic already. (if (null? commits) '() (let ((reporter (make-reporter start-commit end-commit commits))) ;; If it's our first time, verify START-COMMIT's signature. (when (null? authenticated-commits) (verify-introductory-commit repository keyring start-commit signer)) =E2=80=A6)) When START =3D END, the (null? commits) condition is true, and thus =E2=80=98verify-introductory-commit=E2=80=99 is not called. This is the = =E2=80=9Cbug=E2=80=9D, although START =3D END is a situation where there=E2=80=99s not much to do anyway. As I wrote, we could move the =E2=80=98verify-introductory-commit=E2=80=99 = call before the =E2=80=98if=E2=80=99, specifically for this test case, but that doesn= =E2=80=99t strike me as useful; it may also have a visible performance impact on real cases. Thanks, Ludo=E2=80=99.