| 1 |
Rui Covelo writes: |
| 2 |
|
| 3 |
> what about having the public and private key changed |
| 4 |
> periodicaly (developers come and go, keys should come and |
| 5 |
> go too) |
| 6 |
|
| 7 |
GPG keys can have a built-in expiry date. You create the key |
| 8 |
with a life-time of, say 6 months. When that time is up, you |
| 9 |
have to issue a new key. This approach limits the number of |
| 10 |
revocation certificates you have to manage, and the |
| 11 |
administrative overhead is neglectable. (Assuming you don't |
| 12 |
create thousands and thousands of keys every week.) |
| 13 |
|
| 14 |
The good thing about this is that it forces the users to |
| 15 |
maintain their key-rings, because the keys will just stop |
| 16 |
working when the deadline has passed. And, of course, it |
| 17 |
doesn't stop you from issuing revocation certificates |
| 18 |
nonetheless. |
| 19 |
|
| 20 |
|
| 21 |
> and have the portage download automaticaly the public key |
| 22 |
> and revokation certificates [...] |
| 23 |
|
| 24 |
IMHO, the keys should be stored on the public key servers. |
| 25 |
Gentoo may, of course, run its own mirror, but reusing |
| 26 |
infrastructure that exists is a good thing. |
| 27 |
|
| 28 |
I wouldn't want the software to fetch/update/revoke any keys |
| 29 |
automatically, though. Assuming everything is properly |
| 30 |
signed and authenticated, it shouldn't be a problem. But |
| 31 |
automated key-ring management feels wrong to me. |
| 32 |
|
| 33 |
Concerning the "TODO-list" I posted: There is another step I |
| 34 |
forgot to mention. Verifying the hashes of the files that do |
| 35 |
exist isn't quite enough, you also have to make sure that no |
| 36 |
files exist which don't have a hash, so that attackers can't |
| 37 |
add arbitrary files to the tree. |
| 38 |
|
| 39 |
Peter |
| 40 |
|
| 41 |
|
| 42 |
-- |
| 43 |
gentoo-security@g.o mailing list |
Archives