HKP keyservers over SSL

Daniel Kahn Gillmor dkg at
Thu Mar 12 22:33:35 CET 2009

On 03/12/2009 05:08 PM, David Shaw wrote:
> Does anyone implement other than GnuTLS support 5081?  libcurl can be
> built with different crypto libraries.

No, only GnuTLS supports it at the moment, afaict.  But GnuPG linked to
Curl linked to GnuTLS isn't a completely uncommon situation either (e.g.
that's the way the debian gnupg2 packages are configured).  If gnupg
could support it in this particular case, it'd be nice (though i suspect
that's something we'd ultimately need to talk to the curl developers about).

> Named pipes for this are a dangerous hack.  Remember that that curl
> doesn't really process the CURLOPT_SSL* options.  Rather, it passes
> them wholesale to the underlying crypto library.  I don't think we can
> guarantee that all of the libraries involved here (openssl, gnutls,
> nss) will do the right thing with a named pipe (no seeks allowed!).
> Even if they did work today, there is no guarantee it would work
> forever.  It's just not a stable API we can rely on.

Hrm, yeah, that's probably true.

> Of course that works.  As I said before, passing things by file is
> universal.

Actually, looking at curl_easy_setopt(3), it appears that CURLOPT_CAINFO
*doesn't* refer to a file when linked to NSS:

>     When built against NSS this is the directory that the  NSS  cer‐
>     tificate database resides in.

So even passing as a file isn't universal :(  (i've never actually used
curl linked against NSS, fwiw)

It seems to me like client certificate support is something gnupg should
have eventually, but i'm not certain that the feature should hold up
anonymous TLS-wrapped HKP access.  If gnupg were to support it, it would
be an additional argument --keyserver-option, right?

Another way around all of this is would be to not use curl at all, and
implement the TLS layer directly in what's now the curl shim.  This
would also let us follow the HTTP upgrade approach over the same port,
but would mean more code to maintain (and probably wouldn't handle as
many edge cases as nicely as curl does for us automatically).  It would
also probably bind GnuPG to a single TLS library, since i doubt anyone
wants to maintain multiple variants of the shim itself.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090312/028e3672/attachment.pgp>

More information about the Gnupg-devel mailing list