Even so, there are problems. How many users know to change their keyservers? (I wasn't aware of a need to do this until I ran across this problem.)
When it cannot find the key, the software James is using (CPAN or CPANPLUS) reports it as >> gpg: Total number processed: 0 >> gpg: Can't check signature: public key not found >> =3D=3D> BAD/TAMPERED signature detected! <=3D=3D rather than saying "unable to check signature", it says "BAD/TAMPERED signature detected". That's wrong. CPANPLUS reports this as a failure to CPAN Testers, which is annoying. (I believe this will be fixed in a later version, though.) Audrey mentioned (on CPAN Ratings) some bugs with regards to end-of-line issues were fixed in the latest version. I'm sure there are some workarounds to use a different keyserver by default to handle the subkey problem. So I might (re)start signing modules when these issues are fixed. But I think in the long term, the trust issue should be taken care of. I've not heard any feedback on this yet. Darren Chamberlain wrote: > Robert said he's signing his modules with a subkey, and the MIT key > sever (IIRC) does not support subkeys. If you use a different > keyserver, you'll find the key: > > $ grep ^keyserver ~/.gnupg/gpg.conf > keyserver hkp://subkeys.pgp.net > > $ gpg --search 0xBB72D9C5 > Keys 1-2 of 2 for "0xBB72D9C5" > (1) Robert Rothenberg (CPAN) <rrwo[at]cpan.org> > 1024 bit DSA key 5DB01E18, created 2005-11-09 > (2) Robert Rothenberg <robrwo[at]gmail.com> > 1024 bit DSA key 5DB01E18, created 2005-11-09 > > The main key ID is 5DB01E18. If you grabbed this key from the MIT > keyserver, you could probably verify the signature on Pod::Readme > 0.08, assuming the MIT keyserver passed through the subkeys > unmolested.
