On Wed, Jan 30, 2008 at 04:22:01AM +0000, Shawn O. Pearce wrote:
> Pierre Habouzit <madcoder@xxxxxxxxxx> wrote:
> > On Tue, Jan 29, 2008 at 04:10:00AM +0000, Shawn O. Pearce wrote:
> > > * PGP public key storage:
> > >
> > > Use a "hidden" ref called "refs/access-keys" to store a commit.
> > > The access control change log is a normal Git commit chain.
> >
> > This won't work well, because I don't think GnuPG is able to check
> > some signature against an armored GPG public Key (at least I didn't
> > found a way to do that). You have to create one pubring per submitter,
> > wich is kind of a waste in fact, and the format is horribly binary.
>
> Gaaah.
>
> I hate tools that build their own little internal databases of
> objects, and don't let you store their data in other random places,
> like in any random file format you choose[*1*]. ;-)
[for the record I got the joke].
> I just read the GnuPG manual and you are obviously correct. The only
> way to get GnuPG to process a key is to load it onto a keyring.
> We could extract the armored (or binary) public key and load it
> onto a temporary keyring created just for the purpose of verifying
> this connection, but that's rather messy.
That was my point.
> > I don't even know if you really need the versionning of this
> > pseudo-keyring, and if a .git/keyring.gpg isn't enough.
>
> Well, I don't know about that.
>
> People come and go on a project. It would be nice if there was
> a reasonably trusted store available as part of the project, that
> one can verify using a current trusted project member's public key,
> and obtain prior project member's public keys out of. 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.
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.
> > As a side note, you don't really need to use GIT_PUSH_*. It doesn't
> > make anything safer (as the UIDs of a given public key are public
> > information anyways), you just want to know which key signed that data,
> > and the signature holds that information. Hence if you still want to
> > have a flat-file based keyring (which I repeat I don't think gpg
> > supports directly -- and that's really a shame) you'd better index them
> > per key fingerprint than by author name.
>
> Yea, I know, you haven't told me anything I didn't already know.
>
> 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@xxxxxxxxxxxxxxxxx
whereas I ususally contribute to open source projects using
madcoder@xxxxxxxxxx ;)
> Yes, I know the key ids are unique enough for our needs. But dammit,
> they just aren't friendly to work with when you are storing log
> records for later inspection, or maintaing an access list.
Well, I know my gpg key ID, but I'm biased for sure ;)
--
·O· Pierre Habouzit
··O madcoder@xxxxxxxxxx
OOO http://www.madism.org
Attachment:
pgp53jnGh76Ag.pgp
Description: PGP signature
