From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 04 07:18:25 2016 Received: (at 22883) by debbugs.gnu.org; 4 Jun 2016 11:18:25 +0000 Received: from localhost ([127.0.0.1]:53781 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b99ay-000090-Ld for submit@debbugs.gnu.org; Sat, 04 Jun 2016 07:18:24 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b99aw-00008m-Jk for 22883@debbugs.gnu.org; Sat, 04 Jun 2016 07:18:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b99ap-0006IK-PQ for 22883@debbugs.gnu.org; Sat, 04 Jun 2016 07:18:17 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37380) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b99aX-0006HD-JU; Sat, 04 Jun 2016 07:17:57 -0400 Received: from reverse-83.fdn.fr ([80.67.176.83]:46078 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1b99aV-0001bE-4p; Sat, 04 Jun 2016 07:17:55 -0400 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Mike Gerwitz Subject: Re: Authenticating a Git checkout References: <87io14sqoa.fsf@dustycloud.org> <87h9ep8gxk.fsf@gnu.org> <20160426001359.GA23088@jasmine> <874majg0z8.fsf@gnu.org> <87bn3iz1xc.fsf_-_@gnu.org> <87bn3hwpgo.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 17 Prairial an 224 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Date: Sat, 04 Jun 2016 13:17:53 +0200 In-Reply-To: <87bn3hwpgo.fsf@gnu.org> (Mike Gerwitz's message of "Sat, 04 Jun 2016 00:24:55 -0400") Message-ID: <87wpm519um.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 22883 Cc: 22883@debbugs.gnu.org, Christopher Allan Webber , Leo Famulari 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: -6.4 (------) Hi! Mike Gerwitz skribis: > On Fri, Jun 03, 2016 at 18:12:47 +0200, Ludovic Court=C3=A8s wrote: >> First, =E2=80=98git pull=E2=80=99 doesn=E2=80=99t do it for you, you hav= e to pass =E2=80=98--verify=E2=80=99 and >> there=E2=80=99s no way to set it globally. > > That's unfortunate. Does your checkout scenario include a fresh clone? > If so, a pull flag wouldn't help there. > > Leo mentioned a patch; I don't think that'd be too difficult (looking at > other config options in builtin/pull.c), and would be a great idea. It > appears to pass it off to merge.c; that might be a useful area to verify > signatures as well (pull being a fetch && merge/rebase), in a general > sense. Yeah, it wouldn=E2=80=99t be too hard to add to Git proper, I think, but we can even live without it initially. >> Second, even if it did, it would be a shallow check: as Mike notes in >> with the =E2=80=98sign= chk=E2=80=99 >> script, you actually have to traverse the whole commit history and >> authenticate them one by one. But that=E2=80=99s OK, it runs in presuma= bly less >> than a minute on a repo the size of Guix=E2=80=99s, and we could also st= op at >> signed tags to avoid redundant checks. > > Practically speaking, that's probably fine, though note that a signed > tag is just a signed hash of the commit it points to (with some > metadata), so you're trusting the integrity of SHA-1 and nothing > more. > > With that said, the tag points to what will hopefully be a signed > commit, so if you verify the signature of the tag _and_ that commit, > that'd be even better. Git's use of SHA-1 makes cryptographic > assurances difficult/awkward. > > An occasional traversal of the entire DAG by, say, a CI script would > provide some pretty good confidence. I wouldn't say it's necessary for > every pull. Agreed. >> Third, as I wrote before=C2=B9, relying on the OpenPGP web of trust to >> determine whether a commit is =E2=80=9Cvalid=E2=80=9D is inappropriate: = what we want to >> know is whether a commit was made by an authorized person, not whether >> it was made by someone who happens to have an OpenPGP key directly or >> indirectly certified. > > If you want to keep with the convenience of the web of trust, then you > can have a keyring trusting only the appropriate Guix > hackers. Otherwise, I agree. Oh right, we could do something like: gpgv --keyring guix-developers.keyring foo (I realize GSRC uses this idiom already when authenticating source tarballs: .) >> Fourth, there=E2=80=99s inversion of control: =E2=80=98git log=E2=80=99 = & co. call out to =E2=80=98gpg=E2=80=99, >> so if we want to do something different than just =E2=80=98gpg --verify= =E2=80=99, we >> have to put some other =E2=80=98gpg=E2=80=99 script in $PATH. Blech. > > What types of things are you considering? Something as simple as this: --8<---------------cut here---------------start------------->8--- $ git config gpg.program 'gpgv --keyring /dev/null' $ git verify-commit HEAD error: cannot run gpgv --keyring /dev/null: No such file or directory error: could not run gpg. --8<---------------cut here---------------end--------------->8--- :-/ >> Seventh, even if it did, what would we do with the raw ASCII-armored >> OpenPGP signature? GPG and GPGME are waaaay too high-level, so we=E2=80= =99d >> need to implement OpenPGP (in Guile, maybe based on the OpenPGP library >> in Bigloo?)?! > > What about gpgme/libgcrypt?[*] I believe, but haven=E2=80=99t checked carefully, that GPGME is too high-le= vel; libgcrypt is too low-level (it does not implement OpenPGP.) > [*]: I was actually considering writing an FFI for libgcrypt (if it > doesn't exist already), but it made me uncomfortable without studying > whether Guile can make assurances that pointer-referenced data in > "secure" memory will never be copied anywhere else. I was going to > bring it up in the near future on the guile mailing list after I did > some research myself; no need to derail the discussion here. We have incomplete libgcrypt bindings: http://git.savannah.gnu.org/cgit/guix.git/tree/guix/pk-crypto.scm This is used for the authentication of substitutes: https://www.gnu.org/software/guix/manual/html_node/Substitutes.html Thanks for your feedback! Ludo=E2=80=99.