#22883 Trustable "guix pull"

Message #55 received at 22883@debbugs.gnu.org (full text, mbox, reply):

Received: (at 22883) by debbugs.gnu.org; 4 Jun 2016 11:18:25 +0000
From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 04 07:18:25 2016
Received: from localhost ([127.0.0.1]:53781 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	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 <ludo@gnu.org>) 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 <ludo@gnu.org>) 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 <ludo@gnu.org>)
 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 <ludo@gnu.org>)
 id 1b99aV-0001bE-4p; Sat, 04 Jun 2016 07:17:55 -0400
From: ludo@gnu.org (Ludovic Courtès)
To: Mike Gerwitz <mtg@gnu.org>
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 Révolution
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 <cwebber@dustycloud.org>,
 Leo Famulari <leo@famulari.name>
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit@debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request@debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request@debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces@debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
X-Spam-Score: -6.4 (------)

Hi!

Mike Gerwitz <mtg@gnu.org> skribis:

> On Fri, Jun 03, 2016 at 18:12:47 +0200, Ludovic Courtès wrote:
>> First, ‘git pull’ doesn’t do it for you, you have to pass ‘--verify’ and
>> there’s 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’t 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
>> <https://mikegerwitz.com/papers/git-horror-story> with the ‘signchk’
>> script, you actually have to traverse the whole commit history and
>> authenticate them one by one.  But that’s OK, it runs in presumably less
>> than a minute on a repo the size of Guix’s, and we could also stop 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¹, relying on the OpenPGP web of trust to
>> determine whether a commit is “valid” 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:
<http://bzr.savannah.gnu.org/lh/gsrc/trunk/annotate/head:/gar.lib.mk#L217>.)

>> Fourth, there’s inversion of control: ‘git log’ & co. call out to ‘gpg’,
>> so if we want to do something different than just ‘gpg --verify’, we
>> have to put some other ‘gpg’ 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’d
>> need to implement OpenPGP (in Guile, maybe based on the OpenPGP library
>> in Bigloo?)?!
>
> What about gpgme/libgcrypt?[*]

I believe, but haven’t checked carefully, that GPGME is too high-level;
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’.

Send a report that this bug log contains spam.