From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 27 14:48:26 2019 Received: (at 22883) by debbugs.gnu.org; 27 Dec 2019 19:48:26 +0000 Received: from localhost ([127.0.0.1]:57809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ikvaw-0002SW-MT for submit@debbugs.gnu.org; Fri, 27 Dec 2019 14:48:26 -0500 Received: from sender3-of-o51.zoho.com ([136.143.189.51]:21193) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ikvar-0002SL-7b for 22883@debbugs.gnu.org; Fri, 27 Dec 2019 14:48:21 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1577476091; cv=none; d=zohomail.com; s=zohoarc; b=Y+otia0RoX5MCtzyjrL0oWHC1WnGgAEOTcHwcSyKUkyTqvyhLT50QaXhVv7v3345F5DKLdRmCS3OZuMKW+SdL6oUQh1mzJyxjwQnNIGJrQPUM6xjv54qLm49618WDt2n8kYEKd77dx65bqQmRocmn0Qb0PWt5BoB0/roX1JpE04= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1577476091; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=OZI0CreIBzR5vXBv8LYsvTiY8WqjkLByIfFrhNKIfKU=; b=ZyW8IHWjTza8bNwWsop6l+X27k4mldZmnjPbXCxurBlsgE2legV9UbPC4/ZXQalGEyTiFP1P43FNjNDTm+kzQO1jtnF7HlCCJK+F9/GPqPlLJkW6grGi7OayMD1WuQwVJkEPdH9ypF1+cCjGd3ZibN8oWtg+dacAbAknKWLfWEI= 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= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1577476091; s=zoho; d=elephly.net; i=rekado@elephly.net; h=References:From:To:Cc:Subject:In-reply-to:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=OZI0CreIBzR5vXBv8LYsvTiY8WqjkLByIfFrhNKIfKU=; b=OhXICqsh81CKQrECh6PsXP/x3xuS6CisSOrqpAGRHg1NV4VaBExHMkcFprsY0F/F GWAtRISjeypPwmo1rQVqr0gmGKfc/TC49yw+Zg69Tfy5QJQox8/GxPaz4JbZWp60vVV ao1DVtomZL83sh/4rLbcm+JAqKoJ4SmzNBHFbjlo= Received: from localhost (p54AD4C4D.dip0.t-ipconnect.de [84.173.76.77]) by mx.zohomail.com with SMTPS id 1577476089081786.2547125609943; Fri, 27 Dec 2019 11:48:09 -0800 (PST) References: <87io14sqoa.fsf@dustycloud.org> <87h9ep8gxk.fsf@gnu.org> <20160426001359.GA23088@jasmine> <874majg0z8.fsf@gnu.org> <87bn3iz1xc.fsf_-_@gnu.org> <87wpket748.fsf@gnu.org> <87bmkwm8ed.fsf@gnu.org> User-agent: mu4e 1.2.0; emacs 26.3 From: Ricardo Wurmus To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#22883: Authenticating a Git checkout In-reply-to: <87bmkwm8ed.fsf@gnu.org> X-URL: https://elephly.net X-PGP-Key: https://elephly.net/rekado.pubkey X-PGP-Fingerprint: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC Date: Fri, 27 Dec 2019 20:48:05 +0100 Message-ID: <87png9o8i2.fsf@elephly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 22883 Cc: 22883@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Ludovic Court=C3=A8s writes: > Hello, > > Just a note for later=E2=80=A6 > > ludo@gnu.org (Ludovic Court=C3=A8s) skribis: > >> With the quick-hack libgit2 bindings attached, I can run this program, >> which authenticates HEAD: > > [...] > >> So I think we can go from here. Our repo would contain a Scheme list of >> authorized OpenPGP fingerprints, and we=E2=80=99d check whether the fing= erprint >> that shows up in =E2=80=98valid-signature=E2=80=99 above is among them > > Storing the list of authorized keys in a file in the repo is > inconvenient: simply to retrieve it, you=E2=80=99d need to make a checkou= t. So > for each commit we verify, we have to check out the whole repo, which is > inefficient. > > While reading > , I > realized we could store in empty Git commit messages, which would > address the above problem (we could use a custom object type too, but > that would be less convenient.) > > So the special commit could look like: > > Authorization > > (commit-authorizations > (authorization-commit (KEY1 KEY2 =E2=80=A6)) > (files ("hydra.gnu.org.pub") (KEY1 KEY2 =E2=80=A6)) > (files _ (KEY1 KEY2 =E2=80=A6))) ;all other files > > That way, to authenticate a commit, we first fetch the latest > authorization commit, read the authorization rules from there, and make > sure that the changes it makes match the rules. > > Thoughts? Does this *have* to be baked into git? Or are we like the carpenter apprentice who just learned how to use a hammer and considers everything to be a kind of nail=E2=80=A6? I see the appeal of having everything in git as that=E2=80=99s where the co= mmits are that should be authenticated, but using special commit messages seems to me like shoehorning update authorization into a code revision tool. You mentioned that checking signatures on commits is also kinda slow because it=E2=80=99s sequential and not cached. I don=E2=80=99t know what = I really want, but is there perhaps a way to aggregate signatures on past commits so that the client=E2=80=99s work is reduced=E2=80=A6? (I=E2=80=99m very glad you=E2=80=99re thinking about this problem and that = you=E2=80=99ve come up with practical steps forward! I don=E2=80=99t know if my thoughts on this = topic are useful.) -- Ricardo