Re: [Sks-devel] IPv6 and GPG

[Phil Pennock]

On 2009-03-09 at 09:19 -0400, David Shaw wrote:
> What with the recent discussion of IPv6, I'm curious if anyone has  
> tested GPG against it for key retrieval and submission.  It should  
> "just work" with the curl backend, but when GPG is built on a system  
> without curl, an internal HTTP handler is used instead.  I believe  
> this handler code should work fine as written, but I don't believe the  
> IPv6 piece of it has been tested extensively.  If someone could give  
> it a whirl, I'd appreciate it.  To force the use of the internal HTTP  
> handler even when you do have curl installed, you can build GPG with  
> "configure --without-libcurl".

Building with --without-libcurl:

----------------------------8< cut here >8------------------------------
gpg1 gnupg-1.4.9:
% ./bin/gpg --keyserver-options debug --keyserver 'hkp://[2001:980:fff:31::10]' 
 --recv-key $gpg_key
gpg: requesting key 0x3903637F from hkp server [2001:980:fff:31::10]
gpgkeys: curl version = GnuPG curl-shim 1.4.9
* HTTP proxy is "null"
* HTTP URL is 
"http://[2001:980:fff:31::10]:11371/pks/lookup?op=get&options=mr&search=0x3903637F";
* HTTP auth is "null"
* HTTP method is GET
?: [2001: Host not found
gpgkeys: HTTP fetch error 7: couldn't connect: Unknown error: 0
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

gpg2 gnupg-2.0.11:
% ./bin/gpg2 --keyserver-options debug --keyserver 
'hkp://[2001:980:fff:31::10]'  --recv-key $gpg_key
gpg: requesting key 0x3903637F from hkp server [2001:980:fff:31::10]
gpgkeys: curl version = GnuPG curl-shim 2.0.11
* HTTP proxy is "null"
* HTTP URL is 
"http://[2001:980:fff:31::10]:11371/pks/lookup?op=get&options=mr&search=0x3903637F";
* HTTP auth is "null"
* HTTP method is GET
: can't connect to `[2001': host not found
gpgkeys: HTTP fetch error 7: couldn't connect: Not found
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
----------------------------8< cut here >8------------------------------

With the attached patch against gnupg-1.4.9, the key retrieval works.
It's just a matter of handling IP address literals in square brackets.

Reference is RFC3986 / STD66 "Uniform Resource Identifier (URI): Generic
Syntax"

      host        = IP-literal / IPv4address / reg-name
      IP-literal = "[" ( IPv6address / IPvFuture  ) "]"
      IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

In practice, I just check for something in square brackets and take that
as the host portion; a more paranoid check would validate at least the
character set of the enclosed contents and do something other than treat
it as a normal hostname.  But hey, I can confirm that this fix is
sufficient to let retrieval work, so the only issue left is how cautious
you want to be here.

Regards,
-Phil

diff -ur gnupg-1.4.9/util/http.c gnupg-work/util/http.c
--- gnupg-1.4.9/util/http.c     2007-10-23 00:55:31.000000000 -0700
+++ gnupg-work/util/http.c      2009-03-10 22:39:18.000000000 -0700
@@ -343,13 +343,23 @@
              }
 
            strlwr( p );
-           uri->host = p;
+
+           /* Handle a host of [IP] so that [IP:V6]:port works */
+           if( *p == '[' && (p3=strchr( p, ']' )) ) {
+               *p3++ = '\0';
+               /* worst case, uri->host should have length 0, points to \0 */
+               uri->host = p + 1;
+               p = p3;
+           } else {
+               uri->host = p;
+           }
+
            if( (p3=strchr( p, ':' )) ) {
-               *p3++ = 0;
+               *p3++ = '\0';
                uri->port = atoi( p3 );
            }
 
-           uri->host = p;
+           p = uri->host;
            if( (n = remove_escapes( uri->host )) < 0 )
                return G10ERR_BAD_URI;
            if( n != strlen( p ) )

pgpLTEythG9rQ.pgp
Description: PGP signature