Re: [Sks-devel] Fwd: sks-keyserver unavailable

[kristian . fiskerstrand]

The hkps pool should be used with the hkps:// prefix and default to port 443 
not 11371 unless a record telling otherwise is found in SRV 

Sent from my BlackBerry® smartphone on Telenor

-----Original Message-----
From: Niels Laukens <address@hidden>
Sender: address@hidden: Tue, 26 Feb 2013 11:16:11 
To: SKS development list<address@hidden>
Subject: [Sks-devel] Fwd: sks-keyserver unavailable

Hi,

I was redirected to this mailinglist from address@hidden
(original message below).

I'm having trouble getting keys of the pools on sks-keyservers.net. I've
just retried with the suggested debug-option with following result:


$ gpg --keyserver-options debug --recv-key 08ab4849
gpg: requesting key 08AB4849 from hkp server hkps.pool.sks-keyservers.net
gpgkeys: curl version = GnuPG curl-shim
* HTTP proxy is "null"
* HTTP URL is
"http://hkps.pool.sks-keyservers.net:11371/pks/lookup?op=get&options=mr&search=0x08AB4849";
* HTTP auth is "null"
* HTTP method is GET
gpgkeys: HTTP fetch error 7: couldn't connect: End of file
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0


a simultaneous tcpdump shows that I'm talking to 84.215.15.221 which
reverse-resolves to cm-84.215.15.221.getinternet.no.
However, that same tcpdump also shows that it's gpg that initiates the
FIN packet...

Retrying after I flush the DNS-cache works:


$ gpg --keyserver-options debug --recv-key 08ab4849
gpg: requesting key 08AB4849 from hkp server hkps.pool.sks-keyservers.net
gpgkeys: curl version = GnuPG curl-shim
* HTTP proxy is "null"
* HTTP URL is
"http://hkps.pool.sks-keyservers.net:11371/pks/lookup?op=get&options=mr&search=0x08AB4849";
* HTTP auth is "null"
* HTTP method is GET
gpg: key 25BF484F08AB4849: "Niels Laukens" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1


tcpdump tells me it's 131.155.141.70 (mud.stack.nl.)


The problem seems to be highly correlated with the server I'm talking
to. Retrying multiple times usually gives the same result (it keeps
working, or it keeps failing). But I can't spot any "mistakes" on the
server-end in the network dump...


I hope this info is useful for you.



-------- Original Message --------
Subject: Re: Questions about OpenPGP best practices
Date: Tue, 26 Feb 2013 00:14:13 -0800
From: Daniel Kahn Gillmor <address@hidden>
To: GnuPG Users <address@hidden>

On 02/25/2013 11:52 PM, Niels Laukens wrote:
> I find *.sks-keyservers.net unusable (unfortunately).
> 
> More often than not, I get this:
> gpgkeys: HTTP fetch error 7: couldn't connect: End of file
> 
> tcpdump shows me that the server just closes the connection without an
> answer.
> It does work from time to time, so when doing a manual --recv-key, I
> usually get the key within a few tries. But when using e.g. caff (which
> does not retry), it's unusable.

please report this to the sks-devel list, where Kristian has been
supporting these pools.  I think he would appreciate hearing about the
problems you're describing:

 SKS development list <address@hidden>

If you could set "keyserver-options debug" in ~/.gnupg/gpg.conf that
might provide you with more detailed output as well.

> And while pgp.mit.edu might not be the best keyserver, it works... (from
> my experience at least).

If your definition of "works" includes staying well-synced with the
strong set, pgp.mit.edu does not have a great record of working.
Keyservers need to stay up-to-date to be useful.

Regards,

        --dkg





_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel