[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Key policy for GPG verification [was: 2004.2
From:       Marius Mauch <genone () gentoo ! org>
Date:       2004-04-30 20:23:38
Message-ID: 20040430222338.327af167 () sven ! genone ! homeip ! net
[Download RAW message or body]


On 04/30/04  John Davis wrote:

> Portage enhancements are a tough one. I know that genone has emerge
> security almost there and GPG manifest signing is somewhere in the
> middle (need verification here). The problem in making these release
> guidelines is the fact that they are totally dependent on 2 people's
> time and work. Releng does not have control over whether or not these
> can be completed, so putting them on the feature list usually ends up
> being an exercise in futility. If some people are willing to help out
> carpaski and genone, then I will add it to the list, but if they are
> left implementing and testing these two rather substantial features
> themselves, I am not adding them to the list.

Ok, guess I should repeat that the most important thing for GPG signing
(actually the missing part is verification) that's still missing is a
key policy: where to store keys, how to check if they are trustworthy
and so on. If we can agree on a simple and effective solution there it
shouldn't be too difficult to implement this feature (talking about code
here, not the tree). The last time we had a way too long thread with way
too many details and discussions about problem scenarios, please let's
try to avoid that. 
And to get everyone on track I'll start with a very simple proposal
(idea stolen from Spanky IIRC), I won't say that it's really effective
though:
- keys are stored in a keyring and are installed by an ebuild
- a key is trustworthy if it is in that keyring
- expiration is handled by removing the key from that keyring
- each modification to the keyring involves a version bump on the ebuild
That's about the easiest for implementation and doesn't require anything
new for our infrastructure or key-signing-sessions. It does not say who
will manage that keyring though as that is not important for the
implementation. I'm pretty sure that the idea has a number of flaws, but
we have to start somewhere.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]