[Sks-devel] pool.sks-keyservers.net issues

[Phil Pennock]

On 2013-02-28 at 09:12 +0100, Niels Laukens wrote:
> On 2013-02-28 00:50, Phil Pennock wrote:
> > The best fix is to use gpg with a real cURL library.
> 
> I'm currently using a downloaded binary from gpgtools.org. I don't see
> libcurl in the list of shared objects used by the binary (otool -L,
> Mac's equivalent to ldd), so I assume gpg was build without libcurl
> support and I need to build a gpg2 myself. Am I correct?

Or use gpg 1.  Discussion on gnupg-devel points out that my
https://bugs.g10code.com/gnupg/issue1479 bug is a dup of
https://bugs.g10code.com/gnupg/issue739 fixed in 2007.  The same issue
was fixed for GnuPG 1.4.x, but not fixed for GnuPG 2.x.

> I agree with your sentiment on (1). TCP clearly states that this is the
> expected behavior (quote from RFC793 section 3.5):

Standards say one thing, real world experience says another.  The nginx
folks note that they couldn't tell apart "closed for sending" from
"closed entirely", so they just treat the FIN as a sign of an aborted
connection.

> (2) does require a recompile of the binary. I don't mind compiling from
> source, but I think a lot of users won't go further than downloading
> binaries.

Download a gpg 1.4.x binary.

> (3) will solve thing in the future. Is someone already working on a
> patch? Since my options are (a) live with the problem or (b) compile a
> fixed version, I can just as well patch and compile the curl-shim-part.

The GnuPG folks have a patch in tree, they just need to port it across
from the 1.4 branch to the 2.0 branch.

> (4) is obviously the best solution from a user perspective, and combined
> with my (and Phil's) view on (1), also the "right" solution.

Unfortunately, it looks as though nginx has broken the
"proxy_ignore_client_abort on" directive: it doesn't work.

If it did work, I wouldn't now be able to reliably trigger the bug.  I
built gpg2 with the curl-shim on a friend's box in the same colo
network, so it's one unrouted ethernet hop away from my keyserver setup.
With this, I can now trigger it pretty consistently.

I've just bumped my nginx from 1.3.12 to 1.3.13 and the problem
persists.

-Phil