[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
this:
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
packages.
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