From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 03 16:17:20 2016 Received: (at 22883) by debbugs.gnu.org; 3 Jun 2016 20:17:20 +0000 Received: from localhost ([127.0.0.1]:53506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b8vWy-0001t1-Hc for submit@debbugs.gnu.org; Fri, 03 Jun 2016 16:17:20 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:44042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b8vWw-0001st-MF for 22883@debbugs.gnu.org; Fri, 03 Jun 2016 16:17:19 -0400 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6DC302202A; Fri, 3 Jun 2016 16:17:18 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Fri, 03 Jun 2016 16:17:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=famulari.name; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=80/Z0WzwnmvYJ1H/kQnncVLn8PE=; b=gTFI/c qUakZD7uktDZYjPXkoQfeisUEmgjodRtZSlSABI/t/fki4hStBi/p4e62AwlhDCG JQDSXBQ7vUeDQrgqwzXqPXAeVHt72KEaGjtZ2f/xX7oQRYubNmuvulZ2Ppv8xJNF QjF30oMKiuS/INRwiAQsMp807NP1F43GxljJg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=80/Z0WzwnmvYJ1H /kQnncVLn8PE=; b=gLwK+VDh3ognP9RJ3+sO1dzWYWT2r+ii1EXeQs58OpHGtK6 Z+xnxjMj8ZGp8ywZcVHVatZaqF3uxITNAkheIFDNBh9KKjAOaDJGGH1duklkTxMs u8Zp6TonEi/FJss9aNt0U2VZzZ+KgxMn8QM2xDExxpk0UPTg6JsXAmag/N0k= X-Sasl-enc: iEYGC+JHHk8oCExQFdrxDl3FZGAsIj4op6hNcv9ACpXO 1464985038 Received: from localhost (c-68-81-58-201.hsd1.pa.comcast.net [68.81.58.201]) by mail.messagingengine.com (Postfix) with ESMTPA id 190B0CCD3B; Fri, 3 Jun 2016 16:17:18 -0400 (EDT) Date: Fri, 3 Jun 2016 16:17:17 -0400 From: Leo Famulari To: Ludovic =?iso-8859-1?Q?Court=E8s?= Subject: Re: Authenticating a Git checkout Message-ID: <20160603201717.GB32008@jasmine> References: <87io14sqoa.fsf@dustycloud.org> <87h9ep8gxk.fsf@gnu.org> <20160426001359.GA23088@jasmine> <874majg0z8.fsf@gnu.org> <87bn3iz1xc.fsf_-_@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87bn3iz1xc.fsf_-_@gnu.org> User-Agent: Mutt/1.6.0 (2016-04-01) X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22883 Cc: 22883@debbugs.gnu.org, Mike Gerwitz , Christopher Allan Webber 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: -0.7 (/) On Fri, Jun 03, 2016 at 06:12:47PM +0200, Ludovic Courtès wrote: > Hello! > > So we sign Git commits, and now we want to authenticate Git checkouts. > There’s a series of bad news. > > First, ‘git pull’ doesn’t do it for you, you have to pass ‘--verify’ and > there’s no way to set it globally. Since Git already has the git-verify-commit tool, I bet we could convince the Git project to implement this as a repo configuration option. Even better if we brought a patch :) > Second, even if it did, it would be a shallow check: as Mike notes in > 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. That doesn't sound so bad. > 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. IOW, we want to know whether the key used to sign > the commit is among the authorized developer keys. So, we need some sort of Guix keyring system, right? We'd have to verify that a signature was made with an authorized key, and then validate the signature itself? Now it's getting complicated... > 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. > > Fifth, even if we did that, we’d be stuck parsing the possibly l10n’d > output of ‘gpg’. Pretty fragile. According to the man pages gpg(1) and gpg2(1), the value "1" is returned if a signature check fails, and there are "other error codes for fatal errors". If these return values are consistent across GPG versions, maybe they provide enough information for us. Return values are a lot easier to parse than stdout / stderr, in my experience. If we want to go down this path, we should figure out what we'd want to do with GPG besides `gpg --verify`. > Sixth, OK, we’ll use libgit2, and write Guile bindings, maybe based on > the CHICKEN bindings², easy! Well no, it turns out that libgit2³ has no > support for signed commits (the ‘signature’ abstraction there has > nothing to do with OpenPGP signatures.) That's too bad.