Am 2014-08-17 um 10:30 schrieb Jeff King: > On Tue, Aug 12, 2014 at 06:59:17PM -0700, Jonathan Nieder wrote: > >>> + curl_socket_t sockfd = tunnel.out; // what about tunnel.in ? >> >> Hmm. curl expects to get a socket it can send(), recv(), setsockopt(), >> etc on instead of a pair of fds to read() and write(). > > I wonder if we could teach run_command to optionally use socketpair() > instead of pipe().
That sounds like a good idea to me. > I'm not sure if that would cause problems on Windows, > though. Apparently socketpair is not available there. Googling "socketpair windows" yields, among a lot of other useful resources, the following relatively actively maintained ~150 LOC, BSD-3-clause-licensed, implementation: https://github.com/ncm/selectable-socketpair That license is GPL compatible, so should we consider including that implementation with git? That's the kind of stuff that goes to compat/win32, right? One thing to consider: seems like socketpair() gives AF_LOCAL sockets, so I've asked [1] on the curl ML if that would work or if libcurl needs an AF_INET one. >> I wonder why someone would want to use SSL through a tunnel, though. >> Currently it's impossible to get to the SSL codepath when a tunnel is >> active (it's in the 'else' block an 'if (srvc->tunnel)'). If that >> property is preserved, then we should be safe. > > I'm not sure I understand this comment. Even if SSL is not in use, > wouldn't we be passing a regular pipe to curl, which would break? Yeah, we can't do that, and thus would have to keep the handwritten IMAP implementation just for the tunnel case (allowing to drop only the OpenSSL specific stuff), see my other email: http://www.mail-archive.com/git@vger.kernel.org/msg56791.html (the relevant part is pretty far down at the bottom). Bernhard [1] http://curl.haxx.se/mail/lib-2014-08/0131.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
