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