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

[Rick \\\"Zero_Chaos\\\" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.
> - 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
>   $CAT/gentoo-master-keyring
>   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.
>
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShpFdAAoJEKXdFCfdEflKtpQQALDKZfiVfSbRZJEg/fTEvpUo
CpMl+h4zxNxZQV3sE5GTZyhFfTGQ+2B+leS4pxDFgKVSmu+bu6rzYGgU5+BdrvKt
Vg6DrKe56HkmKu6kB28VuXVZ+euXPF0fyjcO/fr3ij1KvEdEz3ALea+GZ1dbEgr4
hD0XV6mKCQZ6qAnaSETpaQERgcXcw/6tgYGAhY4yy5Q+0ECEB6/fe3kWDeDuw0iK
FyLkiawh6GilTmm8h2e5isFipGL+Wqwnqa0xeuJbD/2FlfZjnA3RzsE0vY5Snw4r
9a3UoDHUtGcmNUn5S62iPJRPAzNu1EoYBwAVIMIX5qHmnTSZ+G04lHLeLLLDmr8b
L/W470IP/MhqcKcrXHJlcHvOMDvEz5jxnbPdEcv6dB3FCzaIN6gC80B0sUKco+lU
00Eq3qjneo58zQi01lMsu5LFx0lfL55w/Bb6uRb38RtUcxLgzrTTyLawzqM0KJNw
ZxUX3KcTYHvIBj4ZLEffOmvEBNcIC4R9sDV8aD2ENPQvZt3IH3izCgSKKz7TiiaW
4xmQJtgT8zGSLbuBfSap9wK2+JVSKro97plBxBUe4Ay1hVlYYINRYWusQqciIf3N
KehGd7oAQa6f4QjsxrqknvAEPW9JpAFQRhphkzv+z942kCg4abDUVu8ltuseHDeX
WiUnfhquOGimc8QeXXJx
=UxX6
-----END PGP SIGNATURE-----