Re: [RFC] Authenticate push via PGP signature, not SSH

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jan 31, 2008, 04:30 UTC
Message-ID: <20080131043056.GX24004@spearce.org>
In-Reply-To: <20080130083315.GB8698@artemis.madism.org>

Pierre Habouzit <madcoder@debian.org> wrote:

Show 11 quoted lines

> On Wed, Jan 30, 2008 at 04:22:01AM +0000, Shawn O. Pearce wrote:
> > [...] But maybe the
> > Debian folks just doesn't worry about this as it isn't a real issue.
> 
>   It is, we have since recently the princple of "Debian Maintainers",
> people that are only allowed to upload their own package, and the
> keyring used for that purpose is versionned using a custom development
> of ours called jetring (by Joey Hess and al.), I suppose the sources are
> somewhere around, and it has an internal ascii-armored database IIRC
> _and_ a gpg-usable keyring, I think. Or is able to generate the keyring
> at least.

I looked at jetring earlier today, after you posted the URL in
your other email.  Its an interesting tool for distributed keyring
management.  I can see why the Debian folks use it, but it does seem
a little awkward if one has to create those change files by hand.

Show 7 quoted lines

>   But for the case I discussed, indeed, I'd use
> /usr/share/keyrings/debian-keyring.gpg anyways, and won't be the one
> updating it. That's why your developpement should be able to allow
> checking against another keyring. IOW I'm less and less sure that you
> want to manage the keyring _necessarily_ inside the git tree, and that
> allowing any external way to manage a keyring (inside a git tree beeing
> one of the options) is the most flexible way.

Of this you have convinced me.

If we get any sort of push authorization based upon PGP signatures
implemented we should be validating against a keyring that is
configured by a receive.keyring configuration option, and that
defaults to $GIT_DIR/receive-keyring.gpg or something suitable.
If you want to point receive-pack at an existing keyring on your
system, you can and should do so.

Show 12 quoted lines

> > Having GIT_PUSHER_{NAME,EMAIL} makes it easier for a hook to
> > obtain information about this person and use it in an automated
> > email message.  Think a post-receive hook that automatically sends
> > out announcement emails.
> 
>   okay, that makes sense. Sorry about the obvious parts, it sensed like
> you didn't used gpg on a regular basis, hence wasn't sure of what you
> already knew or not. I agree that for the sake of logging GIT_PUSHER_*
> are nice, since as you can see on the CLI examples I gave, gpg says that
> the email associated to my key is pierre.habouzit@polytechnique.edu
> whereas I ususally contribute to open source projects using
> madcoder@debian.org ;)

A repository owner may require that to push your GIT_PUSHER_* values must match the data found in your PGP key on their keyring, just to keep their logs in a particular way. Others may not care and would allow anything, so long as the signature was validated by a key on the keyring. But I think that level of checking is something we leave up to the repository owner.

Which leads me to three variables:

	GIT_PUSHER_NAME
	GIT_PUSHER_EMAIL
	GIT_PUSHER_KEYID

the latter being important if you really wanted to enforce the $GIT_PUSHER_EMAIL matching the data within the public key used.

-- 
Shawn.