GnuPG folks (since this is cross-posted, if my mail makes it through): there is a bug in GnuPG's SRV handling, I've identified where I think it is, it's in the second block of text from me; the first part of this mail relates to SKS and some policy issues around the new keyserver pool Kristian has added.
On 2012-10-06 at 17:48 +0200, Kristian Fiskerstrand wrote:
> Some background information on this particular pool: My crawler is now
> trying to detect HKPS enabled servers by looking for this SRV record,
> and if no such SRV record is found, attempting to connect and locate a
> SKS stats page on port 443. Servers available on 443 are then included
> as A, AAAA and SRV records, while other SSL-enabled servers are only
> represented as SRV records, as shown in #Snippet 3#
Ah, interesting; in checking, I just discovered that my SRV record for
_pgpkey-https had not been updated since I added nginx proxying, so was
still giving the "0 0 0 ." (explicitly no service here) response, but
what's happening is that you're looking for records on the _server_, I
think, not the "discoverability" records on the _domain_.
Normally, I think the answer is "whatever is given to GnuPG as the
host/domain label in the --keyserver URL". This is a little different.
Not knowing if you're using the hostname from peering records, or the
hostname reported from the lookup?op=stats pages, I've added records for
both. That should cover it, right? Your snippet 3 suggests the
op=stats hostname, but seems safest to just cover both.
(And if I got really unlucky with timing, I'm out of the pool for the
next two hours because of a bogus entry created by forgetting to
re-anchor the RR data after repeating the block in different $ORIGIN
bases. Duh.)
> kristianf@kristianf-precision-m4600:~$ dig +short srv
> _pgpkey-https._tcp.keys.kfwebs.net any
> 10 10 11375 keys.kfwebs.net.
> kristianf@kristianf-precision-m4600:~$ gpg2 --keyserver-options
> no-check-cert,debug,verbose --keyserver hkps://keys.kfwebs.net
> --recv-key 0x0B7F8B60E3EDFAE3
> gpg: requesting key 0B7F8B60E3EDFAE3 from hkps server keys.kfwebs.net
> gpgkeys: curl version = libcurl/7.22.0 GnuTLS/2.12.14 zlib/1.2.3.4
> libidn/1.23 librtmp/2.3
> * About to connect() to keys.kfwebs.net port 443 (#0)
> * Trying 2001:16d8:ee30::4... * connected
Looking at gnupg's keyserver/gpgkeys_hkp.c as of git commit
76055d49d1c8b8e4f6245e6729cae81b1eaecbf6 it looks like you might be
using an older binary than me? If I try that command, I get "Host:",
"Port:", ... lines before the "* About to connect()" line from curl.
Still, doesn't appear to be fixed.
I see the bug: if the scheme is hkps: then they set:
695 if(ascii_strcasecmp(opt->scheme,"hkps")==0)
696 {
697 proto="https";
698 port="443";
699 }
then we hit:
729 if(opt->port)
730 port=opt->port;
731 else if(try_srv)
732 {
733 char *srvtag;
734
735 if(ks_strcasecmp(opt->scheme,"hkp")==0)
736 srvtag="pgpkey-http";
737 else if(ks_strcasecmp(opt->scheme,"hkps")==0)
738 srvtag="pgpkey-https";
739 else
740 srvtag=NULL;
741
742 #ifdef HAVE_LIBCURL
743 /* We're using libcurl, so fake SRV support via our wrapper.
744 This isn't as good as true SRV support, as we do not try all
745 possible targets at one particular level and work our way
746 down the list, but it's better than nothing. */······
747 srv_replace(srvtag);
Now srv_replace will set opt->port:
531 if(newname && newport)
532 {
533 free(opt->host);
534 free(opt->port);
535 opt->host=newname;
536 snprintf(newport,MAX_PORT,"%u",srvlist->port);
537 opt->port=newport;
538 }
but then in get_key():
266 strcpy(request,proto);
267 strcat(request,"://");
268 strcat(request,opt->host);
269 strcat(request,":");
270 strcat(request,port);
271 strcat(request,opt->path);
[...]
294 curl_easy_setopt(curl,CURLOPT_URL,request);
So, there's a `port` and an `opt->port`; the SRV lookups set `opt->port`
but not `port`, while the URL given to curl uses `port`.
It seems like changing 537 to:
port = opt->port = newport
should fix it as a stop-gap.
-Phil
pgpuY3TNNNPWS.pgp
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
