From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 30 11:32:31 2020 Received: (at 22883) by debbugs.gnu.org; 30 Apr 2020 15:32:31 +0000 Received: from localhost ([127.0.0.1]:47500 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUBAs-0007CT-Qv for submit@debbugs.gnu.org; Thu, 30 Apr 2020 11:32:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jUBAq-0007CD-TW for 22883@debbugs.gnu.org; Thu, 30 Apr 2020 11:32:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51649) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUBAk-0004uH-WD; Thu, 30 Apr 2020 11:32:23 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=34390 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jUBAk-00046s-7c; Thu, 30 Apr 2020 11:32:22 -0400 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Ricardo Wurmus Subject: Re: bug#22883: Authenticating a Git checkout 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> <87png9o8i2.fsf@elephly.net> <87fth4bj6y.fsf@gnu.org> Date: Thu, 30 Apr 2020 17:32:19 +0200 In-Reply-To: <87fth4bj6y.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sat, 28 Dec 2019 15:47:49 +0100") Message-ID: <87bln9oupo.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 22883 Cc: 22883@debbugs.gnu.org, Justus Winter 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: -3.3 (---) Hi there! Ludovic Court=C3=A8s skribis: >> 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 wh= at 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? > > The caching implemented in 787766ed1e7f0806a98e696830542da528f957bb > makes things acceptable: the first =E2=80=9Cmake authenticate=E2=80=9D ru= n takes a bit > more than two minutes to check all the commits starting from =E2=80=98v1.= 0.1=E2=80=99, > but subsequent runs take a few seconds. > > I have plans to make things faster (independently of the cache) by doing > OpenPGP signature verification entirely in Scheme instead of spawning > =E2=80=98gpgv=E2=80=99 every time. Again, we=E2=80=99ll have to get a pr= ototype before we can > tell whether it actually is faster. I=E2=80=99ve been able to resume work on that in the =E2=80=98wip-openpgp= =E2=80=99 branch: 5a86b96f54 git-authenticate: Use (guix openpgp). 4e66563449 openpgp: Add 'string->openpgp-packet'. dc0b5d5e01 openpgp: 'lookup-key-by-{id,fingerprint}' return the key first. 740d804621 openpgp: 'verify-openpgp-signature' looks up by fingerprint wh= en possible. 0157c5ef7f openpgp: Add 'lookup-key-by-fingerprint'. 31fc7cf080 openpgp: Store the issuer key id and fingerprint in . c22bede3ce openpgp: Decode the issuer-fingerprint signature subpacket. 74d0d85e49 DRAFT Add (guix openpgp). At this stage, =E2=80=98make authenticate=E2=80=99 uses the pure-Scheme imp= lementation (based on G=C3=B6ran Weinholt=E2=80=99s code, heavily modified). It can au= thenticate 14K+ commits in ~20s instead of 4m20s on my laptop, which is really nice. Signature verification in (guix openpgp) does just that: signature verification. It does not validate signature and key metadata, in particular expiration date. I guess it should at least error out when a signature creation time is newer than its key expiration time. It should also reject SHA1 signatures, at least optionally (I haven=E2=80= =99t checked whether our Git history has any of these). I would very much welcome feedback and advice from an OpenPGP-savvy person (I=E2=80=99ve Cc=E2=80=99d one to maximize the chances of success :-= )). Next steps: =E2=80=A2 Clean up the (guix openpgp) API a bit, for instance by using pr= oper SRFI-35 error conditions. Perhaps handle v5 packets too. =E2=80=A2 Load the keyring from files in the repo, possibly in a dedicated branch. =E2=80=A2 Load the list of authorized keys from the parent of the commit = being authenticated. =E2=80=A2 Generalize that to channels. Ludo=E2=80=99.