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

[Niels Laukens]

Thanks Phil for the very clear summary of the problem!

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?


> So:
>  (1) there's a corner-case interaction of TCP/HTTP and half-closes
>  (2) there's a build work-around for end-sites of the client software
>  (3) there's a code change for the client software that avoids the issue
>  (4) we're working on server configuration fixes to avoid the issue too
> 
> (4) is the only thing that will help currently deployed software bases.
> (3) is the only thing that will keep the issue reliably fixed going
>     forward.
> (2) means people encountering it can work around it now.
> (1) sucks, because I for one like the signalling done and the model used
>     in TCP and used by the GnuPG developers.  It's very clear, "we're
>     not going to send anything else".  Unfortunately, it's causing
>     real-world interoperability issues.  :-(

I agree with your sentiment on (1). TCP clearly states that this is the
expected behavior (quote from RFC793 section 3.5):
> CLOSE is an operation meaning "I have no more data to send."  The
> notion of closing a full-duplex connection is subject to ambiguous
> interpretation, of course, since it may not be obvious how to treat
> the receiving side of the connection.  We have chosen to treat CLOSE
> in a simplex fashion.  The user who CLOSEs may continue to RECEIVE
> until he is told that the other side has CLOSED also.  Thus, a program
> could initiate several SENDs followed by a CLOSE, and then continue to
> RECEIVE until signaled that a RECEIVE failed because the other side
> has CLOSED.

(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.

(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.

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

Niels

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 906 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130228/6b798f8a/attachment.pgp>