| 1 |
On Friday 30 April 2004 21:23, Marius Mauch wrote: |
| 2 |
> Ok, guess I should repeat that the most important thing for GPG signing |
| 3 |
> (actually the missing part is verification) that's still missing is a |
| 4 |
> key policy: where to store keys, how to check if they are trustworthy |
| 5 |
> and so on. If we can agree on a simple and effective solution there it |
| 6 |
> shouldn't be too difficult to implement this feature (talking about code |
| 7 |
> here, not the tree). The last time we had a way too long thread with way |
| 8 |
> too many details and discussions about problem scenarios, please let's |
| 9 |
> try to avoid that. |
| 10 |
> And to get everyone on track I'll start with a very simple proposal |
| 11 |
> (idea stolen from Spanky IIRC), I won't say that it's really effective |
| 12 |
> though: |
| 13 |
> - keys are stored in a keyring and are installed by an ebuild |
| 14 |
> - a key is trustworthy if it is in that keyring |
| 15 |
> - expiration is handled by removing the key from that keyring |
| 16 |
> - each modification to the keyring involves a version bump on the ebuild |
| 17 |
> That's about the easiest for implementation and doesn't require anything |
| 18 |
> new for our infrastructure or key-signing-sessions. It does not say who |
| 19 |
> will manage that keyring though as that is not important for the |
| 20 |
> implementation. I'm pretty sure that the idea has a number of flaws, but |
| 21 |
> we have to start somewhere. |
| 22 |
> |
| 23 |
> Marius |
| 24 |
|
| 25 |
Uh oh.. this again ;-) |
| 26 |
|
| 27 |
The above proposal doesn't allow recovery from a compromise, since someone |
| 28 |
could update the new keys ebuild to a new one containing only their key. The |
| 29 |
master key / monthly signing multi-server keys proposal was better. See the |
| 30 |
archives for details. |
| 31 |
|
| 32 |
-- |
| 33 |
gentoo-dev@g.o mailing list |
Archives