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,
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,
That license is GPL compatible, so should we consider including that
implementation with git? That's the kind of stuff that goes to
One thing to consider: seems like socketpair() gives AF_LOCAL sockets,
so I've asked  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:
relevant part is pretty far down at the bottom).
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