Re: [RFC 0/3] imap-send curl tunnelling support

From: Nicolas Morey-Chaisemartin <nmoreychaisemartin@suse.de>
Date: Aug 21, 2017, 07:34 UTC
Message-ID: <0beb0a6c-acb3-ae24-5c52-95747f74c07f@suse.de>
In-Reply-To: <20170816083432.rgurgckch6phcul3@sigill.intra.peff.net>

Le 16/08/2017 à 10:34, Jeff King a écrit :

Show 9 quoted lines

> On Wed, Aug 09, 2017 at 04:43:26PM +0200, Nicolas Morey-Chaisemartin wrote:
>
>> I have a few doubt on patch #2:
>> - is socketpair working on all git supported system (windows ?)
> I'm pretty sure the answer is no, after searching a bit for mingw and
> socketpair. The big question is whether we could come up with a suitable
> replacement. And that would depend on how libcurl works on Windows, I
> think (because it's going to feed whatever we give it to other syscall
> wrappers).

That's what I feared. I'm not sure there is a portable "anonymous socket" API out there that'll work...

Show 11 quoted lines

>> - should socketpair always be used or limited to the curl over tunnel case ?
>>   I don't think there is too much different between an unname pipe and a socketpair but I'm not sure either :)
> There's not much difference in practice. The obvious one is that
> half-duplex shutdowns require shutdown() on a socket and just close() on
> the write half of a pipe. I don't know if we do that or not.
>
> I'd be inclined to leave the existing code alone, though, just because
> of the risk of regression (and because I don't think the curl and
> non-curl versions actually share that much code). But I haven't looked
> deeply, so I may be wrong.
>

It's easy enough to keep the legacy working without socketpair.

>> It appears curl do not support the PREAUTH tag.
> Too bad. IMHO preauth is the main reason to use a tunnel in the first
> place.

It shouldn't be too hard to add support for this in curl. If it's the main usecase, it'll simply means the curl tunnelling should be disabled by default for older curl (in this case, meaning every version until it gets supported) versions.

Nicolas