Re: [gentoo-project] GPG Keyring distribution & packages

[Brian Dolbec]

On Fri, 2013-11-15 at 16:25 -0500, Rick "Zero_Chaos" Farina wrote:
> On 11/15/2013 02:37 PM, Robin H. Johnson wrote:
> > On Fri, Nov 15, 2013 at 01:51:32PM -0500, Rick "Zero_Chaos" Farina wrote:
> >> On 11/15/2013 01:23 AM, Robin H. Johnson wrote:
> >>> You crossed sections, but let's collapse both to:
> >>>
> >>> Bare minimum requirements:
> >>> 3. Key expiry: 6 months min, 3 years max.
> >>> Recommendations:
> >>> 4.1. Root key: 6 months min, 3 year max;
> >>> 4.2. Signing subkey: 3 months min, 1 year max;
> >>> 4.3. For both keys, expiry date should always be update at least 1 month before expiry.
> >> How are we planning on updating keys on user's systems to verify things?
> >>  I only ask because 3 months on the signing key means whatever we do
> >> needs to happen *securely* every 3 months at most.  So like, if we are
> >> pushing an ebuild with a keyring then we have to update it every 2
> >> months so keys don't expire and then that would break if the user
> >> doesn't update every 3 months...  Might be an issue as we try as a whole
> >> to keep systems updatable for 1 year.
> > So some more details regarding how we plan to deploy keys is probably
> > needed here. It was out of scope for the discussion about what keys
> > should look like.
> >
> > There are a few parts to it:
> > - gentoo-keys (lead by dolsen)
> >   This is a mostly infra-level tool that takes the data in LDAP, does
> >   validation, mixes in the keys from keyserver/homedir, and generates
> >   keyrings.

Not quite right.  The gentoo-keys project is a repository with two main
components.

1) gkeyldap cli and python pkg.  This is all the code that needs to run
on infra machines to get the data from ldap and generate the dev seed
file.  It will likely never be installed on a user system (but some noob
will likely try).  It could be adapted to run on other derivative
distro's with some additional code wrapping or patches.  Or they could
just create their own script to generate the seed files.  Please note
that seed files can be manually generated and maintained using the gkey
app in 2 below.

2) gkey cli and python pkg.

 a) This is the code and library that will be installed on users and
infra systems to manage and install the keys to the appropriate keyring
or keyrings.  It will have code for doing regular maintenance and upkeep
of the keyrings.  As I see it so far, there will be no need for it to
require binary keyrings or ebuilds with version bumps to perform
updates.  It will be able to download updated seed files just like
layman does with the repositories.xml file.  keyring updates can be done
automatically with a cron job, emerge --sync hook or even make use of
it's python API to run the maintenance actions from within the package
manager (see b)

  b)  A python library of predefined functions and methods to perform
the regular verification and maintenance operations.  They will be
available from both the cli interface supplied or through use of it's
python API.

  c) a cli interface for performing all the operations it is capable of.

  d) It leaves open the possibility of getting a gui interface that
users can use for maintenance.  Hey, I wouldn't code it any other way
than to be able to switch out the interface without having to recode the
operational routines.


Ebuild installed seed files could be done as well for overlay use or
other repositories of pkgs whether layman maintained or not.  They would
be subject to regular tree rules.  All that is needed is to install the
keyring's seed file to the gkey seedfile directory and call the gkey cli
with the correct parameters for it to install the keys it specifies.
Something easily done the the pkg_post_intall().

> > - keyring packages:
> >   Thus far, based on the Debian keyring model, where keyrings of trusted
> >   keys are installed locally in /usr/share/keyrings/, and the package
> >   manager (or other tools) looks there for validation. I've got a few
> >   planned so far:
> >   $CAT/gentoo-dev-keyring
> >   $CAT/gentoo-releng-keyring

Yes, the code is set up for those 2 primary seed files and keyrings.
They are not also needed to be installed via ebuild.  The url's will be
included in the pkg,  They will be downloaded and installed the same as
layman's repositories.xml file.  It will save having it be version
bumped up to several times a day in the case of the dev's seed file.
I have yet to add the code in gkeyldap to check if the new seed file has
indeed changed or not before changing the existing seed file.  The gkey
sync operation will send the "if-Modified-since" header like I did for
layman-2.0, so only an updated seed file will trigger an update to the
keys the seed file is responsible for and installed on the user's
system.

The dev keyrings are set up to be one keyring per dev. all under one
umbrella dev-keyring directory.  This was the setup requested by Brian
Harring, to be used for the git commit verification hooks.  It also
provides some cross contamination protection.


> >   $CAT/gentoo-master-keyring
Interesting...  Good idea :)

I have also started setting up a known_seeds variable to be used
similarly to layman's repositories.xml.  It could be for keys known to
us for non-dev commits to official overlays and such.  But have not put
much thought into it.  At any rate the code will be there to handle it
regardless if it comes into being or not.  

> >   To ease the 1-year-updatability requirement, these three packages
> >   should explicitly be signed by the master key (and not a dev key),
> >   which has a much longer validity. This would always enable you to
> >   rsync, install the latest gentoo-dev-keyring, and then install other
> >   packages thereafter.
> I think this is a great idea, BUT, we would need to handle "the latest
> gentoo-dev-keyring" like portage updates used to be handled.  If there
> is an update, warn the user, and if gentoo-dev-keyring is in the update
> list it *must* be merged first.  Again, these implementation details
> don't necessarily have to be in the glep, but we need to make sure as we
> go through that we account for such things.  My day job is pretty much
> running man in the middle on things and laughing at the result, so I'm
> super excited to see all this hard work going in.
>
> > - layman keyrings:
> >   dolsen is also working on allowing overlays to specify keyrings in the
> >   repositories.xml; there's a few unanswered questions about how to
> >   ensure nobody does MITM attacks on those keyrings (either convince the
> >   overlays admins to change the URL to the keyring, or simply intercept
> >   requests for the keyring itself). This maps to how Ubuntu's Launchpad
> >   handles keys for PPAs.
>
> It is really tough to bootstrap things like this.  honestly I would
> suggest that this is good enough and overlay maintainers who really care
> can post things on their website to help further manual verification.
> Not that we should ignore issues here, but I wouldn't spend dozens of
> hours trying to figure out how we secure overlays full of non-gentoo
> official content.  For the official ones we can sign their key with the
> master key and that should take care of any trust issues.

The fingerprint for the overlay's signed seed file could be added to
repositories.xml which is controlled by gentoo devs and signed by the
master key.  That should take care of our end of it.  Of course the user
must take responsibility for installing and using the overlay ebuilds in
the first place, so we can not offer any guarantees as to the validity
of the overlay and the keys it offers unless it is an official overlay.
For that use case any non-dev's must supply an equivalent of a dev's gpg
signing key, following the same rules as dev's for it.  It is those keys
which we may have to create a central repo for, since they will not have
a dev.g.o account to store them in (if that is the route taken).

> >
> > TODO:
> > We need a way for a given repo, once installed, to specify what keyrings
> > to use for validation. I'm thinking of adding it to
> > metadata/layout.conf.
> > The main gentoo-x86 repo would have for example:
> > keyrings = gentoo-master gentoo-releng gentoo-dev
> >
> > Overlays might have:
> > keyrings = gentoo-overlay-mysql
> >
> Love it.  This should probably make it into the glep.
>
> Thanks,
> Zero


Sounds good to me.

P.S.  OH my, this turned out to be along reply :/
But I hope it clears up any questions people may have about it.
It is a work in progress...
-- 
Brian Dolbec <dolsen@g.o>