[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’.
- bug#22883: Authenticating a Git checkout, Ludovic Courtès, 2016/06/03
- bug#22883: Authenticating a Git checkout, Leo Famulari, 2016/06/03
- bug#22883: Authenticating a Git checkout,
Ludovic Courtès <=
- bug#22883: Authenticating a Git checkout, Mike Gerwitz, 2016/06/04
- bug#22883: Authenticating a Git checkout, Ludovic Courtès, 2016/06/04
- bug#22883: Authenticating a Git checkout, Christopher Allan Webber, 2016/06/05
- bug#22883: Authenticating a Git checkout, Leo Famulari, 2016/06/05
- bug#22883: Authenticating a Git checkout, Mike Gerwitz, 2016/06/05
- bug#22883: Authenticating a Git checkout, Ludovic Courtès, 2016/06/06