[Dev] Package signing policy

[Nicolás Reynolds]

El 05/12/11 06:25, Luke T.Shumaker dijo:
> 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.

btw i was just testing the master key thingy, yesterday. now i know what it's
for.

> 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")

haha...

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

In any case "master key" is an unfortunate name, we should consider to change
it too.

I don't see a point in making a hierarchical WOT since it's not the OpenPGP
model but the x509/CA one. 

This remembers me a few weeks ago I thought of a system to represent direct
democracy (assembly mandate, delegation, revocability, etc.) over WOT
relationships, for instance:

Task X must be done so assembly mandates you as a delegate for it ("represent
the assembly at some Y event"), so everybody signs your gpg key with it's
notation (I was suggested by dkg that it should be made on gpg notations but
I didn't understand the spec). This represents the trust/mandate the assembly
put in you on your keyring. If anyone wants to check your status as delegate
they can check your published key.

In this sense, my opinion is that a packager can release packages if other
packagers signed their key. This can be done via the regular ways (meet in
place Z and exchange IDs) but since we're all over the globe we can implement
some sort of Socialist Millonaire Protocol a la OTR, or just sign the notation
for "Parabola Packager" if someone wants to explain me how do they work.

For the initial keyring we just have to sign each other keys and that's it. No
central trusting authority!

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

They shared one many commits ago.


Another idea: since package releasing is done via ssh, we can finally consider
using monkeysphere[0]! :P


[0]: http://web.monkeysphere.info

-- 
Salud!
Nicolás Reynolds,
xmpp:fauno at kiwwwi.com.ar
omb:http://identi.ca/fauno

OTR: C0CB1F0F 01DB5E18 2D634C2A A4626858 E7C7C3A2

http://parabolagnulinux.org
http://endefensadelsl.org

"Freedom [...] is messy" ~ Eben Moglen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20111205/a70840f5/attachment.sig>