#22883 Trustable "guix pull"

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

Received: (at 22883) by debbugs.gnu.org; 4 Jun 2016 04:26:17 +0000
From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 04 00:26:17 2016
Received: from localhost ([127.0.0.1]:53644 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1b93A9-0006Si-9v
	for submit@debbugs.gnu.org; Sat, 04 Jun 2016 00:26:17 -0400
Received: from eggs.gnu.org ([208.118.235.92]:55930)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mtg@gnu.org>) id 1b93A5-0006SS-8J
 for 22883@debbugs.gnu.org; Sat, 04 Jun 2016 00:26:15 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <mtg@gnu.org>) id 1b939y-0007pO-M9
 for 22883@debbugs.gnu.org; Sat, 04 Jun 2016 00:26:08 -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]:34301)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <mtg@gnu.org>)
 id 1b939e-0007ng-QG; Sat, 04 Jun 2016 00:25:46 -0400
Received: from localhost ([::1]:40115 helo=mikegerwitz-pc.gerwitz.local)
 by fencepost.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <mtg@gnu.org>)
 id 1b939e-0007ZP-3w; Sat, 04 Jun 2016 00:25:46 -0400
From: Mike Gerwitz <mtg@gnu.org>
To: ludo@gnu.org (Ludovic Courtès)
Subject: Re: Authenticating a Git checkout
In-Reply-To: <87bn3iz1xc.fsf_-_@gnu.org> ("Ludovic
 \=\?utf-8\?Q\?Court\=C3\=A8s\?\=
 \=\?utf-8\?Q\?\=22's\?\= message of "Fri,
 03 Jun 2016 18:12:47 +0200")
Date: Sat, 04 Jun 2016 00:24:55 -0400
Message-ID: <87bn3hwpgo.fsf@gnu.org>
References: <87io14sqoa.fsf@dustycloud.org> <87h9ep8gxk.fsf@gnu.org>
 <20160426001359.GA23088@jasmine> <874majg0z8.fsf@gnu.org>
 <87bn3iz1xc.fsf_-_@gnu.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
 micalg=pgp-sha1; protocol="application/pgp-signature"
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 (------)

[Message part 1 (text/plain, inline)]

Ludo:

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.

> 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.

> 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.

> 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?  Or are you just considering
the possibility?

I agree that it is awkward.  At the same time, making it configurable
(in the git sense) can potentially be very dangerous, because a
malicious script (e.g. configure) could just modify it to a noop
(e.g. `true`) and circumvent signature checks.

> Fifth, even if we did that, we’d be stuck parsing the possibly l10n’d
> output of ‘gpg’.  Pretty fragile.

In the log output?  You could use --pretty and %G*.  Otherwise, yes
parsing GPG's output seems dangerous; surely there's a better way (like
Leo mentioned).

> Well no, it turns out that libgit2³ has no support for signed commits
> (the ‘signature’ abstraction there has nothing to do with OpenPGP
> signatures.)

!? D:

That's more concerning from a community mindset standpoint than anything.

> 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 stumbled upon git-lockup⁴, which uses something other than OpenPGP to
> sign objects in Git.  However, signatures are not stored in commits but
> rather in “git notes”, which, IIUC, are mutable objects detached from
> the rest of the object store, so not great.

It seems a bit over-complicated.  Without reading much into it, it
doesn't strike me as much different than a detached signature, but the
problem is that the signature (as you implied) can just be
deleted.  Git's commit/tag signatures are embedded in the actual
object.  git-lockup also seems to hash "(branch,commitid) pairs", which
signs considerably less data than Git's signature would (unless it
actually signs the full object, not a string referencing it).


I'll have to read over your first reference (your message) and its
references; now I'm curious.


[*]: 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.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
https://mikegerwitz.com
FSF Member #5804 | GPG Key ID: 0x8EE30EAB

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.