gpg --refresh with large keyrings and hkps in 2.1.1

[Phil Pennock]

On 2014-12-16 at 19:13 -0500, Daniel Kahn Gillmor wrote:
> i'm trying to test "gpg --refresh" with large keyrings in gnupg 2.1.1.
> It's better than it was before, but i'm still getting some errors with a
> larger keyring.
> 
> In particular, i'm seeing an abort when i try to refresh the a large
> keyring against an hkps keyserver; only the first 83 keys get refreshed,
> and then gpg aborts with:
> 
> gpg: keyserver refresh failed: Input/output error

Does the same happen with an hkp keyserver?  You don't explicitly note
that you see things proceed further with hkp, which would lead to
knowing if the problem is with key sizes (on particular key, which you
see 83 keys into your keyring) or with TLS.

If you only see this with TLS, are you able to get a pcap capture of
what's happening and get a protocol trace?

Things which come to mind as avenues for investigation, assuming
TLS-specific:

 * TLS session renegotiation and whether or not the GnuTLS integration
   in GnuPG is missing some callback to allow this
 * keyserver TLS proxy size limits, hitting some particular caching
   limit in size which fits in memory in a common configuration
 * Whether or not smaller keys kept you from reaching MTU-sized packets
   and something bad is happening locally for you with timeouts during
   Path MTU Discovery, only kicking in once the flows are large enough
   inbound

The webpage <http://sks.spodhuis.org/sks-peers> is very ugly, but does
at least show you in-line in the table what the Via: header is (and the
Server: header too).  It might be worth selecting a host each with
"nginx", "Apache", "lighttpd", "Squid", "xs-httpd" and "HAProxy" as the
TLS provider on the server-side.  This will at least let you rule out
client/server TLS interop issues.  You'll probably need to coerce the
hostname to be the pool server, though, to get a validatable certificate
presented to you.  Might be easiest to just hack /etc/hosts around as
needed.

-Phil