GnuPG 2.1.0: key too large, import stops

[Phil Pennock]

On 2014-11-24 at 09:39 +0100, Werner Koch wrote:
> This is intended as a sanity check.  Obviously too short for Joost's
> key.  Increase that to 10MB or even 20MB?

Is there a way to skip the import of that one key, continuing on, so
that one unimportable key doesn't abort the entire keyring?

> > Now just to figure out why I have to keep specifying the keyserver
> > manually ...
> 
> Remember to add use --hkp-cacert for dirmngr; there is no default
> certificate right now, but that will probably change with the next
> release.

Ah, dirmngr.conf and the `keyserver-options ca-cert-file=...` from
gnupg.conf is now ignored, okay.

Some comments from debugging dirmngr:

 * dirmngr.texi suggests a config file containing at least:
       log-file ~/dirmngr.log
   that doesn't work, and looking in common/logging.c:set_file_fd() I
   can see nothing which would expand the string; I think that the only
   handling for ~/ is from the shell, for --options, and that listing
   this for a config file is a documentation bug.
 * supporting ~/ in the config file would be nice :)
 * there's no documentation on the working directory for the daemon; it
   looks like, during daemonization, there's a `chdir("/")`, even for
   per-user daemons?
 * while `http_register_tls_ca()` can be called multiple times, to
   accumulate CAs, as far as I can see there's nothing which lets the
   config option hkp-cacert supply multiple values; I don't think it can
   be repeated?
 * --no-detach doesn't prevent detach with --daemon
 * I can't see a way to get --server to create the Unix socket, to let a
   foreground server be used to answer questions from gpg clients;
   --homedir is not sufficient and the debugging option --socket-name
   doesn't appear to work
 * the hkp-cacert filename *must* end `.pem` if the file is to be read
   in PEM format; this appears to be an undocumented constraint
 * there's no logging or handling for showing why hkps: is failing if
   GnuPG was built without TLS support

And the last point is the critical one: because curl is not being used
anymore and GnuTLS must be available, there's a regression in default
behaviour from the configure command-line given the dependent libraries;
this one isn't anyone's fault, but I think that there probably needs to
be clearer communication to OS packagers that they now need to make sure
that GnuTLS is available.

I'm using FreeBSD Ports, and the FreeBSD Port does not register GnuTLS
as a dependency, and I'm building ports with poudriere, so that each
port build is isolated (this is the default for the packages shipped by
FreeBSD) the end result is a GnuPG package with no TLS support.

I'll fiddle some more to hack my port build.

Regards,
-Phil