[Sks-devel] pool.sks-keyservers.net issues
niels at dest-unreach.be
Thu Feb 28 09:12:50 CET 2013
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?
> (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
> (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
(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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 906 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-users