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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
