{"thread":{"id":"46549","subject":"[RFC 1/3] imap-send: move tunnel setup to its own function","startedAt":"2017-08-09T14:46:14Z","lastAt":"2017-08-24T21:23:16Z","messageCount":22,"participants":["Nicolas Morey-Chaisemartin","Stefan Beller","Jeff King","Johannes Schindelin","Johannes Sixt","Daniel Stenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"325955","messageId":"fd231e01-1eb2-17a8-52e8-19d9c0a2d4a3@morey-chaisemartin.com","threadId":"46549","inReplyTo":"ab866314-608b-eaca-b335-12cffe165526@morey-chaisemartin.com","subject":"[RFC 1/3] imap-send: move tunnel setup to its own function","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"nicolas@morey-chaisemartin.com","sentAt":"2017-08-09T14:46:07Z","receivedAt":"2017-08-09T14:46:14Z","isPatch":false,"sender":{"key":"devel-git@morey-chaisemartin.com","avatar":"https://avatars.githubusercontent.com/u/108326?v=4"},"body":"Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>\n---\n imap-send.c | 37 ++++++++++++++++++++++---------------\n 1 file changed, 22 insertions(+), 15 deletions(-)\n\ndiff --git a/imap-send.c b/imap-send.c\nindex b2d0b849b..10f668eb7 100644\n--- a/imap-send.c\n+++ b/imap-send.c\n@@ -926,6 +926,27 @@ static int auth_cram_md5(struct imap_store *ctx, struct imap_cmd *cmd, const cha\n \treturn 0;\n }\n \n+static void setup_tunnel(struct imap_server_conf *srvc, int fds[2])\n+{\n+\tstruct child_process tunnel = CHILD_PROCESS_INIT;\n+\n+\timap_info(\"Starting tunnel '%s'... \", srvc->tunnel);\n+\n+\targv_array_push(&tunnel.args, srvc->tunnel);\n+\ttunnel.use_shell = 1;\n+\ttunnel.in = -1;\n+\ttunnel.out = -1;\n+\tif (start_command(&tunnel))\n+\t\tdie(\"cannot start proxy %s\", srvc->tunnel);\n+\n+\tfds[0] = tunnel.out;\n+\tfds[1] = tunnel.in;\n+\n+\timap_info(\"ok\\n\");\n+\n+\treturn;\n+}\n+\n static struct imap_store *imap_open_store(struct imap_server_conf *srvc, char *folder)\n {\n \tstruct credential cred = CREDENTIAL_INIT;\n@@ -943,21 +964,7 @@ static struct imap_store *imap_open_store(struct imap_server_conf *srvc, char *f\n \t/* open connection to IMAP server */\n \n \tif (srvc->tunnel) {\n-\t\tstruct child_process tunnel = CHILD_PROCESS_INIT;\n-\n-\t\timap_info(\"Starting tunnel '%s'... \", srvc->tunnel);\n-\n-\t\targv_array_push(&tunnel.args, srvc->tunnel);\n-\t\ttunnel.use_shell = 1;\n-\t\ttunnel.in = -1;\n-\t\ttunnel.out = -1;\n-\t\tif (start_command(&tunnel))\n-\t\t\tdie(\"cannot start proxy %s\", srvc->tunnel);\n-\n-\t\timap->buf.sock.fd[0] = tunnel.out;\n-\t\timap->buf.sock.fd[1] = tunnel.in;\n-\n-\t\timap_info(\"ok\\n\");\n+\t\tsetup_tunnel(srvc, imap->buf.sock.fd);\n \t} else {\n #ifndef NO_IPV6\n \t\tstruct addrinfo hints, *ai0, *ai;\n-- \n2.14.0.3.gb4ff627ec.dirty\n\n\n"},{"id":"325956","messageId":"3f49822c-2766-1904-4449-716dadec958f@morey-chaisemartin.com","threadId":"46549","inReplyTo":"ab866314-608b-eaca-b335-12cffe165526@morey-chaisemartin.com","subject":"[RFC 3/3] imap_send: add support for curl over tunnel","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"nicolas@morey-chaisemartin.com","sentAt":"2017-08-09T14:46:21Z","receivedAt":"2017-08-09T14:46:27Z","isPatch":false,"sender":{"key":"devel-git@morey-chaisemartin.com","avatar":"https://avatars.githubusercontent.com/u/108326?v=4"},"body":"Starting from libcurl 7.21.5, libcurl can be tricked into using\nan already open socket.\nThis allows to use tunneling with libcurl instead of the legacy imap code.\n\nSigned-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>\n---\n Documentation/git-imap-send.txt |  4 ++--\n imap-send.c                     | 45 +++++++++++++++++++++++++++++++++++------\n 2 files changed, 41 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt\nindex 5d1e4c80c..e765c08d7 100644\n--- a/Documentation/git-imap-send.txt\n+++ b/Documentation/git-imap-send.txt\n@@ -38,8 +38,8 @@ OPTIONS\n \tBe quiet.\n \n --curl::\n-\tUse libcurl to communicate with the IMAP server, unless tunneling\n-\tinto it.  Ignored if Git was built without the USE_CURL_FOR_IMAP_SEND\n+\tUse libcurl to communicate with the IMAP server.\n+\tIgnored if Git was built without the USE_CURL_FOR_IMAP_SEND\n \toption set.\n \n --no-curl::\ndiff --git a/imap-send.c b/imap-send.c\nindex e5ff70096..31b93d873 100644\n--- a/imap-send.c\n+++ b/imap-send.c\n@@ -1408,6 +1408,26 @@ static int append_msgs_to_imap(struct imap_server_conf *server,\n }\n \n #ifdef USE_CURL_FOR_IMAP_SEND\n+static curl_socket_t curl_tunnel_socket(void *clientp,\n+\t\t\t\t\tcurlsocktype purpose,\n+\t\t\t\t\tstruct curl_sockaddr *address)\n+{\n+\treturn (unsigned long)clientp;\n+}\n+\n+static int sockopt_callback(void *clientp, curl_socket_t curlfd,\n+\t\t\t\t curlsocktype purpose)\n+{\n+\t/* CURL_SOCKOPT_ALREADY_CONNECTED was intreocued in 7.21.5\n+\t * and is needed to get curl working on an existing fd */\n+#if LIBCURL_VERSION_NUM >= 0x071505\n+\treturn CURL_SOCKOPT_ALREADY_CONNECTED;\n+#else\n+\treturn CURL_SOCKOPT_ERROR;\n+#endif\n+}\n+\n+\n static CURL *setup_curl(struct imap_server_conf *srvc)\n {\n \tCURL *curl;\n@@ -1424,8 +1444,21 @@ static CURL *setup_curl(struct imap_server_conf *srvc)\n \tcurl_easy_setopt(curl, CURLOPT_USERNAME, server.user);\n \tcurl_easy_setopt(curl, CURLOPT_PASSWORD, server.pass);\n \n-\tstrbuf_addstr(&path, server.use_ssl ? \"imaps://\" : \"imap://\");\n-\tstrbuf_addstr(&path, server.host);\n+\tif (srvc->tunnel) {\n+\t\tint fds[2];\n+\n+\t\tsetup_tunnel(srvc, fds);\n+\t\tcurl_easy_setopt(curl, CURLOPT_OPENSOCKETFUNCTION, curl_tunnel_socket);\n+\t\tcurl_easy_setopt(curl, CURLOPT_OPENSOCKETDATA, (unsigned long)fds[0]);\n+\t\tcurl_easy_setopt(curl, CURLOPT_SOCKOPTFUNCTION, sockopt_callback);\n+\t\t/* Create a fake hostname to avoid resolution issue and in case\n+\t\t * imap.host was not set */\n+\t\tstrbuf_addstr(&path, \"imap://localhost\");\n+\t} else {\n+\t\tstrbuf_addstr(&path, server.use_ssl ? \"imaps://\" : \"imap://\");\n+\t\tstrbuf_addstr(&path, server.host);\n+\t}\n+\n \tif (!path.len || path.buf[path.len - 1] != '/')\n \t\tstrbuf_addch(&path, '/');\n \tstrbuf_addstr(&path, server.folder);\n@@ -1570,12 +1603,12 @@ int cmd_main(int argc, const char **argv)\n \n \t/* write it to the imap server */\n \n-\tif (server.tunnel)\n-\t\treturn append_msgs_to_imap(&server, &all_msgs, total);\n-\n #ifdef USE_CURL_FOR_IMAP_SEND\n \tif (use_curl)\n-\t\treturn curl_append_msgs_to_imap(&server, &all_msgs, total);\n+#if LIBCURL_VERSION_NUM < 0x071505\n+\t\tif (!server.tunnel)\n+#endif\n+\t\t\treturn curl_append_msgs_to_imap(&server, &all_msgs, total);\n #endif\n \n \treturn append_msgs_to_imap(&server, &all_msgs, total);\n-- \n2.14.0.3.gb4ff627ec.dirty\n\n"},{"id":"325957","messageId":"ac79ae33-db5a-ae90-5e6d-b6364c77266a@morey-chaisemartin.com","threadId":"46549","inReplyTo":"ab866314-608b-eaca-b335-12cffe165526@morey-chaisemartin.com","subject":"[RFC 2/3] imap-send: use a socketpair instead of pipe to communicate with the tunnel","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"nicolas@morey-chaisemartin.com","sentAt":"2017-08-09T14:46:15Z","receivedAt":"2017-08-09T14:52:59Z","isPatch":false,"sender":{"key":"devel-git@morey-chaisemartin.com","avatar":"https://avatars.githubusercontent.com/u/108326?v=4"},"body":"Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>\n---\n imap-send.c | 17 +++++++++++++----\n 1 file changed, 13 insertions(+), 4 deletions(-)\n\ndiff --git a/imap-send.c b/imap-send.c\nindex 10f668eb7..e5ff70096 100644\n--- a/imap-send.c\n+++ b/imap-send.c\n@@ -929,18 +929,27 @@ static int auth_cram_md5(struct imap_store *ctx, struct imap_cmd *cmd, const cha\n static void setup_tunnel(struct imap_server_conf *srvc, int fds[2])\n {\n \tstruct child_process tunnel = CHILD_PROCESS_INIT;\n+\tint sock_fds[2];\n \n \timap_info(\"Starting tunnel '%s'... \", srvc->tunnel);\n \n+\tif (socketpair(AF_UNIX, SOCK_STREAM, 0, sock_fds))\n+\t\tdie(\"failed to create socketpair for proxy\");\n+\n \targv_array_push(&tunnel.args, srvc->tunnel);\n \ttunnel.use_shell = 1;\n-\ttunnel.in = -1;\n-\ttunnel.out = -1;\n+\ttunnel.in = sock_fds[1];\n+\t/* Duplicate the fd as the child process requires\n+\t * 1 for stdin, one for stdout */\n+\ttunnel.out = dup(sock_fds[1]);\n+\tif (tunnel.out < 0)\n+\t\tdie(\"failed to create fd to proxy\");\n+\n \tif (start_command(&tunnel))\n \t\tdie(\"cannot start proxy %s\", srvc->tunnel);\n \n-\tfds[0] = tunnel.out;\n-\tfds[1] = tunnel.in;\n+\tfds[0] = sock_fds[0];\n+\tfds[1] = sock_fds[0];\n \n \timap_info(\"ok\\n\");\n \n-- \n2.14.0.3.gb4ff627ec.dirty\n\n\n"},{"id":"325958","messageId":"ab866314-608b-eaca-b335-12cffe165526@morey-chaisemartin.com","threadId":"46549","inReplyTo":null,"subject":"[RFC 0/3] imap-send curl tunnelling support","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"nicolas@morey-chaisemartin.com","sentAt":"2017-08-09T14:43:26Z","receivedAt":"2017-08-09T14:53:41Z","isPatch":false,"sender":{"key":"devel-git@morey-chaisemartin.com","avatar":"https://avatars.githubusercontent.com/u/108326?v=4"},"body":"From 7.21.5, curl can be tricked into using an open fd.\nThis series uses this to allow using curl over a tunnel.\n\nI have a few doubt on patch #2:\n- is socketpair working on all git supported system (windows ?)\n- should socketpair always be used or limited to the curl over tunnel case ?\n  I don't think there is too much different between an unname pipe and a socketpair but I'm not sure either :)\n\nThis series also shows a \"bug\" in curl.\nWhen trying out the tunnel example fro imap-send documentation, this happends:\nStarting tunnel 'ssh -q -C localhost /usr/sbin/imapd ./Maildir'... ok\nsending 3 messages\n16:38:54.055221 http.c:639              == Info: Hostname was NOT found in DNS cache\n16:38:54.059505 http.c:639              == Info:   Trying ::1...\n16:38:54.059545 http.c:639              == Info: Connected to localhost () port 143 (#0)\n16:38:54.354379 http.c:586              <= Recv header, 0000000332 bytes (0x0000014c)\n16:38:54.354405 http.c:598              <= Recv header: * PREAUTH [CAPABILITY IMAP4REV1 I18NLEVEL=1 LITERAL+ IDLE UIDPLUS NAMESPACE CHILDREN MAILBOX-REFERRALS BINARY UNSELECT ESEARCH WITHIN SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] Pre-authenticated user nmorey portia.home.nicolas.morey-chaisemartin.com IMAP4rev1 2007e.404 at Wed, 9 Aug 2017 16:38:54 +0200 (CEST)\n16:38:54.354425 http.c:639              == Info: Bad tagged response\n16:38:54.354448 http.c:639              == Info: Closing connection 0\ncurl_easy_perform() failed: FTP: weird server reply\n\nIt appears curl do not support the PREAUTH tag.\n\nHowever a test with \"nc imap.server.ext 143\" is working fine.\n\nNicolas Morey-Chaisemartin (3):\n  imap-send: move tunnel setup to its own function\n  imap-send: use a socketpair instead of pipe to communicate with the\n    tunnel\n  imap_send: add support for curl over tunnel\n\n Documentation/git-imap-send.txt |  4 +-\n imap-send.c                     | 91 +++++++++++++++++++++++++++++++----------\n 2 files changed, 72 insertions(+), 23 deletions(-)\n\n"},{"id":"326422","messageId":"5c46f1e4-825e-8e10-e323-e637e170f315@morey-chaisemartin.com","threadId":"46549","inReplyTo":"ab866314-608b-eaca-b335-12cffe165526@morey-chaisemartin.com","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"nicolas@morey-chaisemartin.com","sentAt":"2017-08-15T17:49:30Z","receivedAt":"2017-08-15T17:59:21Z","isPatch":false,"sender":{"key":"devel-git@morey-chaisemartin.com","avatar":"https://avatars.githubusercontent.com/u/108326?v=4"},"body":"Ping.\n\nI'd like to get feedback from Windows developer on patch #2\nPatch#3 will probably need some updates as I expected Jeff old curl drop patches to make it in.\nAs it seems to be going another way a few more ifdefs will be required\n\nNicolas\n\nLe 09/08/2017 à 16:43, Nicolas Morey-Chaisemartin a écrit :\n> From 7.21.5, curl can be tricked into using an open fd.\n> This series uses this to allow using curl over a tunnel.\n>\n> I have a few doubt on patch #2:\n> - is socketpair working on all git supported system (windows ?)\n> - should socketpair always be used or limited to the curl over tunnel case ?\n>   I don't think there is too much different between an unname pipe and a socketpair but I'm not sure either :)\n>\n> This series also shows a \"bug\" in curl.\n> When trying out the tunnel example fro imap-send documentation, this happends:\n> Starting tunnel 'ssh -q -C localhost /usr/sbin/imapd ./Maildir'... ok\n> sending 3 messages\n> 16:38:54.055221 http.c:639              == Info: Hostname was NOT found in DNS cache\n> 16:38:54.059505 http.c:639              == Info:   Trying ::1...\n> 16:38:54.059545 http.c:639              == Info: Connected to localhost () port 143 (#0)\n> 16:38:54.354379 http.c:586              <= Recv header, 0000000332 bytes (0x0000014c)\n> 16:38:54.354405 http.c:598              <= Recv header: * PREAUTH [CAPABILITY IMAP4REV1 I18NLEVEL=1 LITERAL+ IDLE UIDPLUS NAMESPACE CHILDREN MAILBOX-REFERRALS BINARY UNSELECT ESEARCH WITHIN SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] Pre-authenticated user nmorey portia.home.nicolas.morey-chaisemartin.com IMAP4rev1 2007e.404 at Wed, 9 Aug 2017 16:38:54 +0200 (CEST)\n> 16:38:54.354425 http.c:639              == Info: Bad tagged response\n> 16:38:54.354448 http.c:639              == Info: Closing connection 0\n> curl_easy_perform() failed: FTP: weird server reply\n>\n> It appears curl do not support the PREAUTH tag.\n>\n> However a test with \"nc imap.server.ext 143\" is working fine.\n>\n> Nicolas Morey-Chaisemartin (3):\n>   imap-send: move tunnel setup to its own function\n>   imap-send: use a socketpair instead of pipe to communicate with the\n>     tunnel\n>   imap_send: add support for curl over tunnel\n>\n>  Documentation/git-imap-send.txt |  4 +-\n>  imap-send.c                     | 91 +++++++++++++++++++++++++++++++----------\n>  2 files changed, 72 insertions(+), 23 deletions(-)\n>\n\n"},{"id":"326427","messageId":"CAGZ79kbgYqo=6FvRNwB0AOKT8mioPTu2CearVttA30nZ8wBMHQ@mail.gmail.com","threadId":"46549","inReplyTo":"5c46f1e4-825e-8e10-e323-e637e170f315@morey-chaisemartin.com","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-08-15T18:18:08Z","receivedAt":"2017-08-15T18:18:13Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Aug 15, 2017 at 10:49 AM, Nicolas Morey-Chaisemartin\n<nicolas@morey-chaisemartin.com> wrote:\n> Ping.\n>\n> I'd like to get feedback from Windows developer on patch #2\n> Patch#3 will probably need some updates as I expected Jeff old curl drop patches to make it in.\n> As it seems to be going another way a few more ifdefs will be required\n\n+cc Windows devs\n\n>\n> Nicolas\n>\n> Le 09/08/2017 à 16:43, Nicolas Morey-Chaisemartin a écrit :\n>> From 7.21.5, curl can be tricked into using an open fd.\n>> This series uses this to allow using curl over a tunnel.\n>>\n>> I have a few doubt on patch #2:\n>> - is socketpair working on all git supported system (windows ?)\n>> - should socketpair always be used or limited to the curl over tunnel case ?\n>>   I don't think there is too much different between an unname pipe and a socketpair but I'm not sure either :)\n>>\n>> This series also shows a \"bug\" in curl.\n>> When trying out the tunnel example fro imap-send documentation, this happends:\n>> Starting tunnel 'ssh -q -C localhost /usr/sbin/imapd ./Maildir'... ok\n>> sending 3 messages\n>> 16:38:54.055221 http.c:639              == Info: Hostname was NOT found in DNS cache\n>> 16:38:54.059505 http.c:639              == Info:   Trying ::1...\n>> 16:38:54.059545 http.c:639              == Info: Connected to localhost () port 143 (#0)\n>> 16:38:54.354379 http.c:586              <= Recv header, 0000000332 bytes (0x0000014c)\n>> 16:38:54.354405 http.c:598              <= Recv header: * PREAUTH [CAPABILITY IMAP4REV1 I18NLEVEL=1 LITERAL+ IDLE UIDPLUS NAMESPACE CHILDREN MAILBOX-REFERRALS BINARY UNSELECT ESEARCH WITHIN SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] Pre-authenticated user nmorey portia.home.nicolas.morey-chaisemartin.com IMAP4rev1 2007e.404 at Wed, 9 Aug 2017 16:38:54 +0200 (CEST)\n>> 16:38:54.354425 http.c:639              == Info: Bad tagged response\n>> 16:38:54.354448 http.c:639              == Info: Closing connection 0\n>> curl_easy_perform() failed: FTP: weird server reply\n>>\n>> It appears curl do not support the PREAUTH tag.\n>>\n>> However a test with \"nc imap.server.ext 143\" is working fine.\n>>\n>> Nicolas Morey-Chaisemartin (3):\n>>   imap-send: move tunnel setup to its own function\n>>   imap-send: use a socketpair instead of pipe to communicate with the\n>>     tunnel\n>>   imap_send: add support for curl over tunnel\n>>\n>>  Documentation/git-imap-send.txt |  4 +-\n>>  imap-send.c                     | 91 +++++++++++++++++++++++++++++++----------\n>>  2 files changed, 72 insertions(+), 23 deletions(-)\n>>\n>\n"},{"id":"326493","messageId":"20170816083432.rgurgckch6phcul3@sigill.intra.peff.net","threadId":"46549","inReplyTo":"ab866314-608b-eaca-b335-12cffe165526@morey-chaisemartin.com","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-16T08:34:32Z","receivedAt":"2017-08-16T08:34:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 09, 2017 at 04:43:26PM +0200, Nicolas Morey-Chaisemartin wrote:\n\n> I have a few doubt on patch #2:\n> - is socketpair working on all git supported system (windows ?)\n\nI'm pretty sure the answer is no, after searching a bit for mingw and\nsocketpair. The big question is whether we could come up with a suitable\nreplacement. And that would depend on how libcurl works on Windows, I\nthink (because it's going to feed whatever we give it to other syscall\nwrappers).\n\n> - should socketpair always be used or limited to the curl over tunnel case ?\n>   I don't think there is too much different between an unname pipe and a socketpair but I'm not sure either :)\n\nThere's not much difference in practice. The obvious one is that\nhalf-duplex shutdowns require shutdown() on a socket and just close() on\nthe write half of a pipe. I don't know if we do that or not.\n\nI'd be inclined to leave the existing code alone, though, just because\nof the risk of regression (and because I don't think the curl and\nnon-curl versions actually share that much code). But I haven't looked\ndeeply, so I may be wrong.\n\n> It appears curl do not support the PREAUTH tag.\n\nToo bad. IMHO preauth is the main reason to use a tunnel in the first\nplace.\n\n-Peff\n"},{"id":"326494","messageId":"20170816083924.uzukuqdz254iglhr@sigill.intra.peff.net","threadId":"46549","inReplyTo":"7ee8331d-e154-7539-e000-4087406f39fa@suse.de","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-16T08:39:25Z","receivedAt":"2017-08-16T08:39:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 15, 2017 at 07:46:11PM +0200, Nicolas Morey-Chaisemartin wrote:\n\n> Patch#3 will probably need some updates as I expected Jeff old curl drop patches to make it in.\n> As it seems to be going another way a few more ifdefs will be required\n\nI'm not sure where we're going with the old-curl versions thing, but I\ndon't think it matters much either way for imap-send. If we drop support\nfor anything, it will be versions of curl less than 7.19.4. But curl\ndidn't get imap support until 7.34.0 (or at least that's what our\nMakefile checks for), so I think that's effectively the oldest version\nyou'd be dealing with here.\n\n(Which I think means your 7.21.5 #ifdef in patch 3 could never trigger).\n\n-Peff\n"},{"id":"326502","messageId":"alpine.DEB.2.21.1.1708161429510.19382@virtualbox","threadId":"46549","inReplyTo":"CAGZ79kbgYqo=6FvRNwB0AOKT8mioPTu2CearVttA30nZ8wBMHQ@mail.gmail.com","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-08-16T12:30:08Z","receivedAt":"2017-08-16T12:30:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 15 Aug 2017, Stefan Beller wrote:\n\n> On Tue, Aug 15, 2017 at 10:49 AM, Nicolas Morey-Chaisemartin\n> <nicolas@morey-chaisemartin.com> wrote:\n> > Ping.\n> >\n> > I'd like to get feedback from Windows developer on patch #2\n> > Patch#3 will probably need some updates as I expected Jeff old curl drop patches to make it in.\n> > As it seems to be going another way a few more ifdefs will be required\n> \n> +cc Windows devs\n\nI can has easy-to-pull branch, please?\n\nThanks,\nDscho\n"},{"id":"326854","messageId":"4a5f9d64-0709-b6b0-c398-6887f1f7f4c0@morey-chaisemartin.com","threadId":"46549","inReplyTo":"alpine.DEB.2.21.1.1708161429510.19382@virtualbox","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"nicolas@morey-chaisemartin.com","sentAt":"2017-08-21T07:27:03Z","receivedAt":"2017-08-21T07:33:29Z","isPatch":false,"sender":{"key":"devel-git@morey-chaisemartin.com","avatar":"https://avatars.githubusercontent.com/u/108326?v=4"},"body":"(Sent a reply from my phone while out of town but couldn't find it so here it is again)\n\nIt's available on my github:\nhttps://github.com/nmorey/git/tree/dev/curl-tunnel\n\nThe series had been stlighly changed since the patch were posted, mostly to add the proper ifdefs to handle older curl versions.\n\nNicolas\n\nLe 16/08/2017 à 14:30, Johannes Schindelin a écrit :\n> Hi,\n>\n> On Tue, 15 Aug 2017, Stefan Beller wrote:\n>\n>> On Tue, Aug 15, 2017 at 10:49 AM, Nicolas Morey-Chaisemartin\n>> <nicolas@morey-chaisemartin.com> wrote:\n>>> Ping.\n>>>\n>>> I'd like to get feedback from Windows developer on patch #2\n>>> Patch#3 will probably need some updates as I expected Jeff old curl drop patches to make it in.\n>>> As it seems to be going another way a few more ifdefs will be required\n>> +cc Windows devs\n> I can has easy-to-pull branch, please?\n>\n> Thanks,\n> Dscho\n\n"},{"id":"326855","messageId":"0beb0a6c-acb3-ae24-5c52-95747f74c07f@suse.de","threadId":"46549","inReplyTo":"20170816083432.rgurgckch6phcul3@sigill.intra.peff.net","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"nmoreychaisemartin@suse.de","sentAt":"2017-08-21T07:34:19Z","receivedAt":"2017-08-21T07:34:25Z","isPatch":false,"sender":{"key":"nmoreychaisemartin@suse.de","avatar":"https://gravatar.com/avatar/5546322ccb9067f56b6939d9d5c758a40cab5b978b1379fd6ec8ab9b8a6a12b1?d=mp&s=160"},"body":"\n\nLe 16/08/2017 à 10:34, Jeff King a écrit :\n> On Wed, Aug 09, 2017 at 04:43:26PM +0200, Nicolas Morey-Chaisemartin wrote:\n>\n>> I have a few doubt on patch #2:\n>> - is socketpair working on all git supported system (windows ?)\n> I'm pretty sure the answer is no, after searching a bit for mingw and\n> socketpair. The big question is whether we could come up with a suitable\n> replacement. And that would depend on how libcurl works on Windows, I\n> think (because it's going to feed whatever we give it to other syscall\n> wrappers).\n\nThat's what I feared.\nI'm not sure there is a portable \"anonymous socket\" API out there that'll work...\n\n>> - should socketpair always be used or limited to the curl over tunnel case ?\n>>   I don't think there is too much different between an unname pipe and a socketpair but I'm not sure either :)\n> There's not much difference in practice. The obvious one is that\n> half-duplex shutdowns require shutdown() on a socket and just close() on\n> the write half of a pipe. I don't know if we do that or not.\n>\n> I'd be inclined to leave the existing code alone, though, just because\n> of the risk of regression (and because I don't think the curl and\n> non-curl versions actually share that much code). But I haven't looked\n> deeply, so I may be wrong.\n>\nIt's easy enough to keep the legacy working without socketpair.\n\n>> It appears curl do not support the PREAUTH tag.\n> Too bad. IMHO preauth is the main reason to use a tunnel in the first\n> place.\n\nIt shouldn't be too hard to add support for this in curl.\nIf 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.\n\nNicolas\n"},{"id":"326945","messageId":"63e3ebea-ad4e-14d7-1170-594390af8e06@kdbg.org","threadId":"46549","inReplyTo":"4a5f9d64-0709-b6b0-c398-6887f1f7f4c0@morey-chaisemartin.com","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-08-22T17:10:14Z","receivedAt":"2017-08-22T17:10:20Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 21.08.2017 um 09:27 schrieb Nicolas Morey-Chaisemartin:\n> (Sent a reply from my phone while out of town but couldn't find it so here it is again)\n> \n> It's available on my github:\n> https://github.com/nmorey/git/tree/dev/curl-tunnel\n> \n> The series had been stlighly changed since the patch were posted, mostly to add the proper ifdefs to handle older curl versions.\n\nThis does not build for me on Windows due to a missing socketpair() \nfunction. But I am working in an old environment, so I do not know \nwhether this statement has much value.\n\n-- Hannes\n"},{"id":"326953","messageId":"0851413b-b83a-7290-76d4-249a49eb30c9@morey-chaisemartin.com","threadId":"46549","inReplyTo":"63e3ebea-ad4e-14d7-1170-594390af8e06@kdbg.org","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"nicolas@morey-chaisemartin.com","sentAt":"2017-08-22T18:22:52Z","receivedAt":"2017-08-22T18:23:04Z","isPatch":false,"sender":{"key":"devel-git@morey-chaisemartin.com","avatar":"https://avatars.githubusercontent.com/u/108326?v=4"},"body":"This was sadly kind of expected...\nI need to look for another way to handle this on Windows.\n\nThanks for the test\n\nNicolas\n\nLe 22/08/2017 à 19:10, Johannes Sixt a écrit :\n> Am 21.08.2017 um 09:27 schrieb Nicolas Morey-Chaisemartin:\n>> (Sent a reply from my phone while out of town but couldn't find it so here it is again)\n>>\n>> It's available on my github:\n>> https://github.com/nmorey/git/tree/dev/curl-tunnel\n>>\n>> The series had been stlighly changed since the patch were posted, mostly to add the proper ifdefs to handle older curl versions.\n>\n> This does not build for me on Windows due to a missing socketpair() function. But I am working in an old environment, so I do not know whether this statement has much value.\n>\n> -- Hannes\n\n"},{"id":"327093","messageId":"20170823214349.k4ayl2urqepch7p4@sigill.intra.peff.net","threadId":"46549","inReplyTo":"0beb0a6c-acb3-ae24-5c52-95747f74c07f@suse.de","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-23T21:43:49Z","receivedAt":"2017-08-23T21:43:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 21, 2017 at 09:34:19AM +0200, Nicolas Morey-Chaisemartin wrote:\n\n> >> It appears curl do not support the PREAUTH tag.\n> > Too bad. IMHO preauth is the main reason to use a tunnel in the first\n> > place.\n> \n> It shouldn't be too hard to add support for this in curl.\n> If it's the main usecase, it'll simply means the curl tunnelling\n> should be disabled by default for older curl (in this case, meaning\n> every version until it gets supported) versions.\n\nYes, I agree. I was hoping when we started this discussion that we were\nmore ready to switch to curl-by-default. But sadly, that isn't close to\nbeing the case. But hopefully we can at least end up with logic that\nlets us use it in the easy cases (no tunneling) and falls back in the\nharder ones.\n\n-Peff\n"},{"id":"327099","messageId":"alpine.DEB.2.21.1.1708240033440.19382@virtualbox","threadId":"46549","inReplyTo":"63e3ebea-ad4e-14d7-1170-594390af8e06@kdbg.org","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-08-23T22:35:53Z","receivedAt":"2017-08-23T22:36:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Hannes,\n\nOn Tue, 22 Aug 2017, Johannes Sixt wrote:\n\n> Am 21.08.2017 um 09:27 schrieb Nicolas Morey-Chaisemartin:\n> > (Sent a reply from my phone while out of town but couldn't find it so here\n> > it is again)\n> > \n> > It's available on my github:\n> > https://github.com/nmorey/git/tree/dev/curl-tunnel\n> > \n> > The series had been stlighly changed since the patch were posted, mostly to\n> > add the proper ifdefs to handle older curl versions.\n> \n> This does not build for me on Windows due to a missing socketpair() function.\n> But I am working in an old environment, so I do not know whether this\n> statement has much value.\n\nSame problem in Git for Windows' SDK:\n\nimap-send.c: In function 'setup_tunnel':\nimap-send.c:936:6: error: implicit declaration of function 'socketpair'; did you\n mean 'socket'? [-Werror=implicit-function-declaration]\n  if (socketpair(AF_UNIX, SOCK_STREAM, 0, sock_fds))\n      ^~~~~~~~~~\n      socket\nimap-send.c: In function 'curl_tunnel_socket':\nimap-send.c:1416:9: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]\n  return (unsigned long)clientp;\n         ^\n\n"},{"id":"327112","messageId":"e11d4449-8377-dbd7-3ad5-441baf7446b6@morey-chaisemartin.com","threadId":"46549","inReplyTo":"20170823214349.k4ayl2urqepch7p4@sigill.intra.peff.net","subject":"[RFC 0/3] imap-send curl tunnelling support","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"nicolas@morey-chaisemartin.com","sentAt":"2017-08-24T08:00:47Z","receivedAt":"2017-08-24T08:01:03Z","isPatch":false,"sender":{"key":"devel-git@morey-chaisemartin.com","avatar":"https://avatars.githubusercontent.com/u/108326?v=4"},"body":"\n\nLe 23/08/2017 à 23:43, Jeff King a écrit :\n> On Mon, Aug 21, 2017 at 09:34:19AM +0200, Nicolas Morey-Chaisemartin wrote:\n>\n>>>> It appears curl do not support the PREAUTH tag.\n>>> Too bad. IMHO preauth is the main reason to use a tunnel in the first\n>>> place.\n>> It shouldn't be too hard to add support for this in curl.\n>> If it's the main usecase, it'll simply means the curl tunnelling\n>> should be disabled by default for older curl (in this case, meaning\n>> every version until it gets supported) versions.\n> Yes, I agree. I was hoping when we started this discussion that we were\n> more ready to switch to curl-by-default. But sadly, that isn't close to\n> being the case. But hopefully we can at least end up with logic that\n> lets us use it in the easy cases (no tunneling) and falls back in the\n> harder ones.\n>\n> -Peff\nI opened a bug upstream and they already fixed this.\nhttps://github.com/curl/curl/pull/1820\n\nAt least bleeding edge curl user should be able to use this.\nI'm not sure where to go with these patches now.\n\n1) There does not seem to be an easy/clean workaround for the lack of socketpair on windows.\nFidling with a loopback AF_UNIX?AF_LOCAL socket should work but it means creating a socket file somewhere which pulls a lot of potential issues (where to put it ? Post-mortem cleanup ? Parallel imap-send ?)\n\n2) The PREAUTH support won't largely be available  for a while (curl, release, distro, etc.)\n- If this is the main use case, it does not make much sense to puch curl; tunneling support without this. I could push the code and only enable the curl tunneling for the next curl release ?\n  Meaning no one (or close to no one) would use this until some later\n  This also means very little testing (apart from mine) until the next curl version gets widely available\n- If this is not the main case (or at least the non PREAUTH is important enough), it would make sense to get this changes in.\n  But it would probably need some more to code to either fallback to legacy mode when curl failed (due to PREAUTH) or detect PREAUTH and directly use the legacy mode.\n\nNicolas\n\n"},{"id":"327127","messageId":"20170824135331.27wtwicjuoiyremx@sigill.intra.peff.net","threadId":"46549","inReplyTo":"e11d4449-8377-dbd7-3ad5-441baf7446b6@morey-chaisemartin.com","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-24T13:53:32Z","receivedAt":"2017-08-24T13:53:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 24, 2017 at 10:00:47AM +0200, Nicolas Morey-Chaisemartin wrote:\n\n> > Yes, I agree. I was hoping when we started this discussion that we were\n> > more ready to switch to curl-by-default. But sadly, that isn't close to\n> > being the case. But hopefully we can at least end up with logic that\n> > lets us use it in the easy cases (no tunneling) and falls back in the\n> > harder ones.\n>\n> I opened a bug upstream and they already fixed this.\n> https://github.com/curl/curl/pull/1820\n\nCool! That's much faster than I had expected. :)\n\n> At least bleeding edge curl user should be able to use this.\n> I'm not sure where to go with these patches now.\n> \n> 1) There does not seem to be an easy/clean workaround for the lack of socketpair on windows.\n> Fidling with a loopback AF_UNIX?AF_LOCAL socket should work but it\n> means creating a socket file somewhere which pulls a lot of potential\n> issues (where to put it ? Post-mortem cleanup ? Parallel imap-send ?)\n\nEven if you create a non-anonymous socket and connect to both ends, I'm\nnot sure how it works to pass that to the spawned child. IIRC, our\nrun_command emulation cannot pass arbitrary descriptors to the child\nprocesses (but I don't know the details of why that is the case, or if\nthere are windows-specific calls we could be making to work around it).\n\n> 2) The PREAUTH support won't largely be available  for a while (curl,\n> release, distro, etc.)\n> - If this is the main use case, it does not make much sense to puch\n> curl; tunneling support without this. I could push the code and only\n> enable the curl tunneling for the next curl release ?\n>   Meaning no one (or close to no one) would use this until some later\n>   This also means very little testing (apart from mine) until the next\n> curl version gets widely available\n> - If this is not the main case (or at least the non PREAUTH is\n> important enough), it would make sense to get this changes in.\n>   But it would probably need some more to code to either fallback to\n> legacy mode when curl failed (due to PREAUTH) or detect PREAUTH and\n> directly use the legacy mode.\n\nIt seems like we should be able to hit the cases that we know work out\nof the box, and just hold back the default for the others. Like:\n\n  static int use_curl_auto(void)\n  {\n  #ifndef USE_CURL_FOR_IMAP_SEND\n\t/* not built; we cannot use it */\n\treturn 0;\n  #else\n\tif (srvc->tunnel) {\n  #if LIBCURL_VERSION < ...\n\t\t/* no preauth support */\n\t\treturn 0;\n  #else\n\t\treturn 1;\n  #endif /* LIBCURL_VERSION < ... */\n\t}\n\t... other checks go here ...\n  #endif /* USE_CURL */\n  }\n\n  ...\n  int use_curl = -1; /* auto */\n  ... set use_curl to 0/1 from --curl/--no-curl command line */\n  if (use_curl < 0)\n      use_curl = use_curl_auto();\n\nI'm not sure what other cases are left. But over time we'd hope that\nuse_curl_auto() would shrink to just \"return 1\", at which point\neverybody is using it (and we can drop the fallback code).\n\n-Peff\n"},{"id":"327128","messageId":"alpine.DEB.2.20.1708241554520.5192@tvnag.unkk.fr","threadId":"46549","inReplyTo":"20170824135331.27wtwicjuoiyremx@sigill.intra.peff.net","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2017-08-24T14:02:19Z","receivedAt":"2017-08-24T14:10:24Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Thu, 24 Aug 2017, Jeff King wrote:\n\n>> I opened a bug upstream and they already fixed this. \n>> https://github.com/curl/curl/pull/1820\n>\n> Cool! That's much faster than I had expected. :)\n\nYour wish is our command! =)\n\n-- \n\n  / daniel.haxx.se (who landed the IMAP PREAUTH fix in curl)\n"},{"id":"327130","messageId":"2875ec38-9d22-ef94-28e5-7b9c6855139d@morey-chaisemartin.com","threadId":"46549","inReplyTo":"20170824135331.27wtwicjuoiyremx@sigill.intra.peff.net","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"nicolas@morey-chaisemartin.com","sentAt":"2017-08-24T14:15:04Z","receivedAt":"2017-08-24T14:15:12Z","isPatch":false,"sender":{"key":"devel-git@morey-chaisemartin.com","avatar":"https://avatars.githubusercontent.com/u/108326?v=4"},"body":"\n\nLe 24/08/2017 à 15:53, Jeff King a écrit :\n> On Thu, Aug 24, 2017 at 10:00:47AM +0200, Nicolas Morey-Chaisemartin wrote:\n>\n>>> Yes, I agree. I was hoping when we started this discussion that we were\n>>> more ready to switch to curl-by-default. But sadly, that isn't close to\n>>> being the case. But hopefully we can at least end up with logic that\n>>> lets us use it in the easy cases (no tunneling) and falls back in the\n>>> harder ones.\n>> I opened a bug upstream and they already fixed this.\n>> https://github.com/curl/curl/pull/1820\n> Cool! That's much faster than I had expected. :)\n>\n>> At least bleeding edge curl user should be able to use this.\n>> I'm not sure where to go with these patches now.\n>>\n>> 1) There does not seem to be an easy/clean workaround for the lack of socketpair on windows.\n>> Fidling with a loopback AF_UNIX?AF_LOCAL socket should work but it\n>> means creating a socket file somewhere which pulls a lot of potential\n>> issues (where to put it ? Post-mortem cleanup ? Parallel imap-send ?)\n> Even if you create a non-anonymous socket and connect to both ends, I'm\n> not sure how it works to pass that to the spawned child. IIRC, our\n> run_command emulation cannot pass arbitrary descriptors to the child\n> processes (but I don't know the details of why that is the case, or if\n> there are windows-specific calls we could be making to work around it).\nWell as long as we can map it on a fd, the dup2 trickery should allow to remap whatever solution we pick to stdin/stdout.\nCould this code be put in a #ifndef WINDOWS ?\n\n>\n>> 2) The PREAUTH support won't largely be available  for a while (curl,\n>> release, distro, etc.)\n>> - If this is the main use case, it does not make much sense to puch\n>> curl; tunneling support without this. I could push the code and only\n>> enable the curl tunneling for the next curl release ?\n>>   Meaning no one (or close to no one) would use this until some later\n>>   This also means very little testing (apart from mine) until the next\n>> curl version gets widely available\n>> - If this is not the main case (or at least the non PREAUTH is\n>> important enough), it would make sense to get this changes in.\n>>   But it would probably need some more to code to either fallback to\n>> legacy mode when curl failed (due to PREAUTH) or detect PREAUTH and\n>> directly use the legacy mode.\n> It seems like we should be able to hit the cases that we know work out\n> of the box, and just hold back the default for the others. Like:\n>\n>   static int use_curl_auto(void)\n>   {\n>   #ifndef USE_CURL_FOR_IMAP_SEND\n> \t/* not built; we cannot use it */\n> \treturn 0;\n>   #else\n> \tif (srvc->tunnel) {\n>   #if LIBCURL_VERSION < ...\n> \t\t/* no preauth support */\n> \t\treturn 0;\n>   #else\n> \t\treturn 1;\n>   #endif /* LIBCURL_VERSION < ... */\n> \t}\n> \t... other checks go here ...\n>   #endif /* USE_CURL */\n>   }\n>\n>   ...\n>   int use_curl = -1; /* auto */\n>   ... set use_curl to 0/1 from --curl/--no-curl command line */\n>   if (use_curl < 0)\n>       use_curl = use_curl_auto();\n>\n> I'm not sure what other cases are left. But over time we'd hope that\n> use_curl_auto() would shrink to just \"return 1\", at which point\n> everybody is using it (and we can drop the fallback code).\n>\n\nThis code works but I'm not that confortable getting code into master that will have been pretty much untested (I doubt there are many git pu/next user that run the bleeding edge curl on their setup)\nand that may just break down once curl gets updated.\nIt has only been tested using the example line from imap-send man page which is a tiny coverage and I'm sure there are some IMAP server with funky interpreation of the standard out there (who said Exchange?)\n\nNicolas\n\n"},{"id":"327132","messageId":"20170824142841.wqcbjwaajhy5ppvl@sigill.intra.peff.net","threadId":"46549","inReplyTo":"2875ec38-9d22-ef94-28e5-7b9c6855139d@morey-chaisemartin.com","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-24T14:28:41Z","receivedAt":"2017-08-24T14:28:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 24, 2017 at 04:15:04PM +0200, Nicolas Morey-Chaisemartin wrote:\n\n> >> 1) There does not seem to be an easy/clean workaround for the lack of socketpair on windows.\n> >> Fidling with a loopback AF_UNIX?AF_LOCAL socket should work but it\n> >> means creating a socket file somewhere which pulls a lot of potential\n> >> issues (where to put it ? Post-mortem cleanup ? Parallel imap-send ?)\n> > Even if you create a non-anonymous socket and connect to both ends, I'm\n> > not sure how it works to pass that to the spawned child. IIRC, our\n> > run_command emulation cannot pass arbitrary descriptors to the child\n> > processes (but I don't know the details of why that is the case, or if\n> > there are windows-specific calls we could be making to work around it).\n> Well as long as we can map it on a fd, the dup2 trickery should allow to remap whatever solution we pick to stdin/stdout.\n> Could this code be put in a #ifndef WINDOWS ?\n\nGood point. So yeah, in theory you could emulate socketpair() with a\ntemporary path to do the rendezvous. Just bind/listen/accept in a\nnon-blocking way, then connect() from the same process, then close() the\nlistener and delete the socket path.\n\nOf course that doesn't work if you don't have AF_UNIX in the first\nplace. You could always do the same trick with TCP sockets over the\nloopback, but now you get the added bonus of wondering whether whoever\nconnected is the other half of your process. ;)\n\nI dunno. I am well out of my range of Windows knowledge, and I don't\nhave a system to test on to determine whether my suggestions are going\ncompletely off the deep end.\n\n-Peff\n"},{"id":"327133","messageId":"20170824143044.tu375seveoktinlm@sigill.intra.peff.net","threadId":"46549","inReplyTo":"alpine.DEB.2.20.1708241554520.5192@tvnag.unkk.fr","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-08-24T14:30:44Z","receivedAt":"2017-08-24T14:30:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 24, 2017 at 04:02:19PM +0200, Daniel Stenberg wrote:\n\n> On Thu, 24 Aug 2017, Jeff King wrote:\n> \n> > > I opened a bug upstream and they already fixed this.\n> > > https://github.com/curl/curl/pull/1820\n> > \n> > Cool! That's much faster than I had expected. :)\n> \n> Your wish is our command! =)\n\nOh good. While I have you here, have you given any thought to a curl\nhandle that has two half-duplex file descriptors, rather than a single\nfull-duplex socket? That would let us tunnel over pipes rather than\nworrying about the portability of socketpair().\n\nI suspect it would be quite complicated, because I imagine that lots of\ninternal bits of curl assume there's a single descriptor.\n\n>  / daniel.haxx.se (who landed the IMAP PREAUTH fix in curl)\n\nDon't you land most of the fixes in curl? :)\n\n-Peff\n"},{"id":"327160","messageId":"alpine.DEB.2.20.1708242302210.24274@tvnag.unkk.fr","threadId":"46549","inReplyTo":"20170824143044.tu375seveoktinlm@sigill.intra.peff.net","subject":"Re: [RFC 0/3] imap-send curl tunnelling support","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2017-08-24T21:22:55Z","receivedAt":"2017-08-24T21:23:16Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Thu, 24 Aug 2017, Jeff King wrote:\n\n> Oh good. While I have you here, have you given any thought to a curl handle \n> that has two half-duplex file descriptors, rather than a single full-duplex \n> socket? That would let us tunnel over pipes rather than worrying about the \n> portability of socketpair().\n>\n> I suspect it would be quite complicated, because I imagine that lots of \n> internal bits of curl assume there's a single descriptor.\n\nYeah, it would take quite some surgery deep down in the heart of curl to \nimplement something like that. It wouldn't call it impossible but it would \ntake a certain level of determination and amount of time. I presume the \ndescriptor-pair would be passed in via an API so it wouldn't affect the \nconnect phase. We also have decent test coverage, making an overhaul like this \na less scary thought - as if the existing tests say OK we can be fairly \ncertain there aren't any major regressions...\n\n(I may also have forgotten some tiny detail for the moment that makes it very \nhard.)\n\n>>  / daniel.haxx.se (who landed the IMAP PREAUTH fix in curl)\n>\n> Don't you land most of the fixes in curl? :)\n\nI do, but I don't expect readers of the git list to know that!\n\n-- \n\n  / daniel.haxx.se\n"}]}