| 1 |
> that's all i got, i'm sure the other guys that were there can chime |
| 2 |
> in with |
| 3 |
> their experiences (i almost got rajiv to ride piggy back ... maybe |
| 4 |
> next year) |
| 5 |
|
| 6 |
key word is _almost_ ... |
| 7 |
|
| 8 |
several (but unfortunately not all) of the devs verified gpg key |
| 9 |
fingerprints. those of you who did should now sign keys. <http:// |
| 10 |
dev.gentoo.org/~rajiv/LWE2006Boston/> has instructions. |
| 11 |
|
| 12 |
|
| 13 |
wolf31o2 and i also had an interesting conversation with david shaw |
| 14 |
of the gpg project. apparently gpg 1.4.3 has a some new features to |
| 15 |
automatically pull public keys from an ldap server or a dns zone |
| 16 |
based on a uid. this might solve the problem of how to distribute |
| 17 |
devs' public keys with portage and manifest signing. if we setup a |
| 18 |
publicly accessible ldap server with the proper schema at ldap:// |
| 19 |
keys.gentoo.org/ then properly configured gpg setups will |
| 20 |
automatically download keys as needed. |
| 21 |
|
| 22 |
here is the relevant note from the gnupg 1.4.3 announce email: |
| 23 |
|
| 24 |
> * New auto-key-locate option that takes an ordered list of methods |
| 25 |
> to locate a key if it is not available at encryption time (-r or |
| 26 |
> --recipient). Possible methods include "cert" (use DNS CERT as |
| 27 |
> per RFC2538bis, "pka" (use DNS PKA), "ldap" (consult the LDAP |
| 28 |
> server for the domain in question), "keyserver" (use the |
| 29 |
> currently defined keyserver), as well as arbitrary keyserver |
| 30 |
> URIs that will be contacted for the key. |
| 31 |
> |
| 32 |
> * Able to retrieve keys using DNS CERT records as per RFC-2538bis |
| 33 |
> (currently in draft): http://www.josefsson.org/rfc2538bis |
| 34 |
|
| 35 |
-- |
| 36 |
gentoo-dev@g.o mailing list |
Archives