bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22883: Authenticating a Git checkout


From: Ludovic Courtès
Subject: bug#22883: Authenticating a Git checkout
Date: Sat, 04 Jun 2016 13:04:05 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Leo Famulari <address@hidden> skribis:

> 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 :)

Sure.  :-)

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

Fundamentally, it’s very simple.  It’s just that OpenPGP is not designed
to do this, and GPG doesn’t help with such uses.

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

The problem is the meaning of a “signature failure.”  We need to
distinguish between the cases that appear in ‘signature-case’:

  http://git.savannah.gnu.org/cgit/guix.git/tree/guix/pki.scm#n179

The ‘gpg’ command hardly helps with that, plus a signature is considered
“valid” if it’s made by someone “trusted” in the sense of the WoT.

Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]