[Dev] Package signing policy

Luke T.Shumaker lukeshu at sbcglobal.net
Mon Dec 5 23:25:29 GMT 2011

At Mon, 05 Dec 2011 17:50:45 -0500,
Luke T.Shumaker wrote:
> At Mon, 5 Dec 2011 16:40:12 -0300,
> Nicolás Reynolds wrote:
> > Hi, I've asked angvp from Arch about the package signing policy that Arch will
> > have. Apparently nothing's decided yet, but they're implementing this:
> > 
> > * There will be 5 "master keys" from 5 notorious Arch devs
> > 
> > * A packager key must be signed for at least 3 of the master keys to upload
> >   packages
> > 
> > * This policy will be coded in dbscripts 
> > 
> > * Pacman does other stuff
> > 
> > * Keys would be signed by other Arch packagers
> > 
> > Disclaimer: this is my own interpretation of what angvp told me ;)
> > 
> > He'll document himself a little more to give us information. But I think now is
> > the moment to define our own package signing policy.
> > 
> > IMO they should be simple and democratic :D
> Agreed, Arch's policy sounds no fun.

Actually, on further reflection, this sounds mostly reasonable. We
have a few "core" hackers whose keys are in the system. Others can be
added fairly organically by having other hackers sign their key.

In my mind, this gives us 2 parameters to tune (our settings would
likely be more liberal than Arch's):
 * How many "generations" away from the "master" keys can sign
   packages? The Arch policy says 1, I'd propose 2 or 3. Think of it
   like an Erdos Number. (I propose the the term "Fauno Number")
 * How does one have their key become a master key? I have 2 ideas on
    1. You get to have a master key when you are in /hackers. I mean,
       at that point everyone knows you're involved with Parabola.
    2. You get promoted to a master key when you have signed X many

Relatedly, since this would affect dbscripts; Why are our dbscripts
not maintained as a fork of Arch's dbscripts so that we can "easily"
pull? The git repos share no history.

~ Luke Shumaker

More information about the Dev mailing list