git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Pierre Habouzit <madcoder@debian.org>
Date
Jan 31, 2008, 09:25 UTC
Message-ID
<20080131092527.GC24403@artemis.madism.org>
In-Reply-To
<20080131043056.GX24004@spearce.org>
On Thu, Jan 31, 2008 at 04:30:56AM +0000, Shawn O. Pearce wrote:
Show 13 quoted lines
> 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 :)
Show 16 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.
  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
Previous: Shawn O. PearceNext: Sam Vilain
Message 17 of 21 in “[RFC] Authenticate push via PGP signature, not SSH”
  1. Sam VilainJan 28, 2008
  2. Shawn O. PearceJan 28, 2008
  3. Jan HudecJan 28, 2008
  4. Sam VilainJan 28, 2008
  5. Shawn O. PearceJan 29, 2008
  6. Shawn O. PearceJan 29, 2008
  7. Pierre HabouzitJan 29, 2008
  8. Shawn O. PearceJan 30, 2008
  9. Sam VilainJan 30, 2008
  10. Shawn O. PearceJan 30, 2008
  11. Pierre HabouzitJan 30, 2008
  12. Sam VilainJan 30, 2008
  13. Johannes SixtJan 30, 2008
  14. Shawn O. PearceJan 31, 2008
  15. Pierre HabouzitJan 30, 2008
  16. Shawn O. PearceJan 31, 2008
  17. Pierre HabouzitJan 31, 2008
  18. Sam VilainJan 30, 2008
  19. Shawn O. PearceJan 30, 2008
  20. Sam VilainJan 31, 2008
  21. Pierre HabouzitJan 28, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.