[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [RFC] Authenticate push via PGP signature, not SSH
From:       Pierre Habouzit <madcoder () debian ! org>
Date:       2008-01-31 9:25:27
Message-ID: 20080131092527.GC24403 () artemis ! madism ! org
[Download RAW message or body]

On Thu, Jan 31, 2008 at 04:30:56AM +0000, Shawn O. Pearce wrote:
> Pierre Habouzit <madcoder@debian.org> wrote:
> >   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.

  Well, *I* don't use it, it's just a fancy tool that replaces the fully
manual (sigh) Debian keyring management for the DM keyring, so that it
can be used by multiple people at the same time. I just pointed to it,
as like you said, reinventing the wheel sucks. Though Joey will probably
be open to improvements if needed :)

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

  Full ACK. Another issue that I didn't saw in the first place, is that
if you want to store your keyring in git itself, then it brings the
issue that you would have to write ACLs to protect the branch where it's
stored, whereas it's usually _way_ more easy to just decorrelate both.
IOW it's weak wrt security.
-- 
 ·O ·  Pierre Habouzit
 · ·O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[Attachment #3 (application/pgp-signature)]
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[prev in list] [next in list] [prev in thread] [next in thread]