Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - pgp key handling

[Brian Dolbec]

++++++++++...

I have been working on the gentoo-keys project [1] to actively maintain
the gentoo gpg keys installation, validation, etc. for users, devs and
servers.  

On Wed, 2013-10-30 at 08:33 +0800, Patrick Lauer wrote:
> On 10/29/2013 09:23 PM, Andreas K. Huettel wrote:
> > In two weeks from now, the council will again have its regular monthly
> > meeting. Now is the time to raise and prepare items that the council should
> > put on the agenda to discuss or vote on.
>
> Request: A minimal policy for pgp keys and key handling (for commit signing)
>
> - Define the allowed key parameters:
> 	e.g. 2048bit RSA or DSA, validity at least 6 months
>

I have it to a point that it would be easy to create a template to
semi-automate the process of creating/updating the keys.  But a spec is
needed for it.  That spec can be another file that can be updated and
downloaded automatically when ever that functionality is used.  No need
for a new release of the app with the changes.

> - Define a canonical location (e.g. in LDAP and on at least one
> keyserver) where every dev's key is accessible (at least to gentoo infra)
>

I have code done which I run from woodpecker (or some other ldap
accessible system) for mining the gpg keys from ldap and creates the
seed file from that info.  Last I test ran it, there were still a number
of devs with mismatched keys and fingerprints. and one without a gpg key
or fingerprint.   Currently it is a little awkward to run from my dev
space due to the +x restriction.  It has to be run via "python2.x
ldap-seeds" currently.

Setting up some automation or having it installed is a next step that
needs discussion.  It will have a python interface that can be
incorporated into last summer's GSOC projects that mgorny and dastergon
were working on, which could do entry validation and trigger the seed
file updates.


> - Define a location of a (signed, autoupdated) global keyring that is
> accessible to all interested parties (e.g.
> http://www.gentoo.org/keyring.txt )
>

The seed file will be made available similar to layman's
repositories.xml list 
eg: https://api.gentoo.org/overlays/repositories.xml

From the seed lists available there, any or all the dev or relaease
media keys can be installed (using the seed info to get the key from the
key server, check the fingerprints match, etc..))  the cli interface
will have convenience functions for checking and validating the release
media and other downloads.


I am in the process of updating mirrorselect's code to get it's lists
from:
MIRRORS_3_XML = 'https://api.gentoo.org/mirrors/distfiles.xml'
MIRRORS_RSYNC_DATA = 'https://api.gentoo.org/mirrors/rsync.xml'


> That's the first stage that can be done now without big problems, and it
> can be amended at any later time if there's any deficiencies.
> (so if we agree that 2048 bit are not enough we just fix it to 4096 bit
> and a three-month migration time)
>
> With that in place we can make commit signing mandatory (because right
> now we don't even have a way to fetch all keys, so it's worse than
> useless).

Last I was actively working on it, I was about to start coding the git
commit validation hook.  But got injured/concussion that put that on
hold.

>
> And then as a third stage we can discuss things like, say, disabling
> commit access when the key is less than a month valid (after sending
> some automated warning mails, yes?) and other ways to make this meaningful.
>
> But - let's not get carried away in a big debate about how the NSA has
> infiltrated the minds of at least three devs, so we need four signatures
> on every commit before it goes live, and other unrelated madness. Just
> define the minimum set of rules to make signing useful, and then figure
> out how to enforce it.
>
> (As a sidenote, someone might want to figure out how to do remote signed
> commits - last time this was discussed I think there were some minor
> issues that should be worked out so that we're all not too affected with
> workflow changes)
>
> Thanks,
>
> Patrick
>


P.S.  I welcome anyone to join in and help with it's development.

 [1] http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-keys.git;a=summary

-- 
Brian Dolbec <dolsen@g.o>