Re: backports
On Thu, Jul 05, 2007 at 09:44:55 +0100, Chris Lale wrote:
[...]
> Strange. I can ping the Debian keyserver:
>
> $ ping keyring.debian.org
> PING keyring.debian.org (192.25.206.59) 56(84) bytes of data.
> 64 bytes from raff.debian.org (192.25.206.59): icmp_seq=1 ttl=40 time=158 ms
>
> but I cannot get the key from it. This is for a new user "dave":
>
> dave@desktop:/home/chris$ gpg --keyserver keyring.debian.org --recv-key 4B2B2B9E
> gpg: directory `/home/dave/.gnupg' created
> gpg: can't open `/gnupg/options.skel': No such file or directory
That is bug #412508. The file is /usr/share/gnupg/options.skel in
Debian. You can copy it yourself and adjust the permissions:
cp -i /usr/share/gnupg/options.skel ~/.gnupg/gpg.conf
chmod 600 ~/.gnupg/gpg.conf
Then you can look though the file and activate/change settings as
desired. (Almost all of it is commented out by default.) You can also
delete the first three lines; see the remark in the first line.
> gpg: keyring `/home/dave/.gnupg/secring.gpg' created
> gpg: keyring `/home/dave/.gnupg/pubring.gpg' created
> gpg: requesting key 4B2B2B9E from hkp server keyring.debian.org
> gpg: no valid OpenPGP data found.
> gpg: read_block: read error: invalid packet
> gpg: Total number processed: 0
> gpg: keyserver timed out
> gpg: keyserver receive failed: keyserver error
I just created my own "dave" and tried the same thing. I could
immediately download the key even though I got the same message about
options.skel. I think your problem is a network issue. I have sometimes
had similar trouble with various keyservers even though my network
connection seemed completely fine otherwise. These problems were always
temporary and went away without me doing anything.
I would not spend too much energy on keyring.debian.org. Downloading
keys from there is just as vulnerable to a man-in-the-middle attack as
is downloading from any other keyserver. Just find a reliable keyserver
close to you and use that one. If everything else fails then you can use
db.debian.org for manual key retrieval.
[ snip: hkp://subkeys.pgp.net works better, but not 100%. This might
happen because it uses round robin DNS to connect you to a different
keyserver every time. ]
> Florian Kulzer wrote:
> > The "ultimately trusted" key should be your own. Did you experiment with
> > gpg in the past and generate a key (pair) which you deleted again?
>
> The new user "dave" had not previously used gpg.
Strange that gpg looks for a specific key ID in that case.
> Perhaps I need to configure an ultimately trusted key (for the new user) to
> avoid these keyserver errors?
That is a quick thing to try, but I don't think this will help (see
above).
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
Reply to: