Re: [PATCH v2 6/6] imap-send: correctly report "host" when using "tunnel"

From: Jeff King <peff@peff.net>
Date: Feb 7, 2023, 22:15 UTC
Message-ID: <Y+LNitGAude1vogv@coredump.intra.peff.net>
In-Reply-To: <230207.86fsbh2nqo.gmgdl@evledraar.gmail.com>

On Tue, Feb 07, 2023 at 09:39:48PM +0100, Ævar Arnfjörð Bjarmason wrote:

> *nod* I'll just note that you elided the part where I noted that I don't
> really care, and will submit some re-roll that's compatible with the
> current imap.{host,tunnel} interaction.

Yeah, sorry, I should have said "yes, thank you" there. :) I wasn't meaning to continue arguing, but just trying to answer your "how would they even find this?" confusion.

> I.e. if we just say that we're not going to support this use-case
> anymore we can get rid of all of the OpenSSL reliance in-tree, except
> for the optional (and hardly ever used) OPENSSL_SHA1, and
> uses-only-one-API-function "HAVE_OPENSSL_CSPRNG" use.

Yeah, getting rid of that openssl code is a reasonable goal. And this may seem counter-intuitive, but I'm actually _more_ in favor of that than the change you proposed here, even though it potentially breaks more users. That's because I feel like we're buying something useful with it, whereas with the patch we've been discussing, the tradeoff was less clear to me.

That said, it seems like there should be a path forward for supporting tunnels via curl, and then we could be getting rid of the openssl dependency _and_ all of the custom and rarely-run imap code. But that's an even bigger task, and I not only wouldn't want to work on it, I'm not even sure I'd want to review it. I'm slightly regretting getting involved here at all, because it seems like none of us actually care at all about imap-send, and this has turned into a big discussion. I mostly chimed in because it seemed like I had a perspective you didn't on how people might use tunnels, and it felt like I should speak up for folks whose use cases might be getting broken.

  Side note: If somebody were proposing to add imap-send at all today,
  I'd probably say "no, that should be a separate project, and you
  should probably write it in some language that has a decent imap
  library". It really has nothing at all to do with Git in terms of
  implementation, and I suspect it's not super well maintained in
  general. But perhaps it is too late for that.

Show 15 quoted lines

> So your example of:
> 
> 	[imap]
> 	host = internal.example.com
> 	tunnel = "ssh bastion-server nc internal.example.com 143"
> 
> Would instead be:
> 
> 	1. Arrange for the equivalent of that to run outside of
> 	   git-imap-send, e.g.:
> 
> 	    ssh -N -R 1430:internal.example.com:143 bastion-server
> 
> 	2. Use "imap.host" to connect to that "remote" box with libcurl,
> 	   but just use "localhost:1430"

Having done something like that before, the "arrange" step is more finicky than you might think (because sometimes it goes away, and you really want to trigger it on demand).

-Peff