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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 7, 2023, 20:39 UTC
Message-ID: <230207.86fsbh2nqo.gmgdl@evledraar.gmail.com>
In-Reply-To: <Y+KYwsBjty0aaLes@coredump.intra.peff.net>

On Tue, Feb 07 2023, Jeff King wrote:

Show 32 quoted lines

> On Sun, Feb 05, 2023 at 10:51:04PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> > Not if they did:
>> >
>> >   [imap]
>> >   host = example.com
>> >   tunnel = some-command
>> 
>> Yes, but how would they have ended up doing that? By discarding the
>> documentation and throwing things at the wall & hoping they'd stick? 
>
> That's what I would have tried without reading the documentation at all,
> based on using other programs that tunnel imap. I'm just one data point,
> of course.
>
>> I just don't get how anyone could have come to rely on this so that we'd
>> care about supporting it.
>> 
>> Because mutt has a feature that looks similar, users might have
>> configured git-imap-send thinking it might do the same thing, and gotten
>> lucky?
>
> It's less "mutt happens to do it this way" and more "associating a host
> is strictly more useful, because it lets you interact with all the other
> host-like features". It's only imap-send's funky config scheme that
> makes it easy to mis-configure.
>
>> I guess in principle that could be true, but I think it's more likely
>> that nobody's ever had reason to use it that way. I.e. if you use the
>> "tunnel" the way the docs suggest you won't hit the credential helper,
>> as you're authenticating with "ssh", and using "imapd" to directly
>> operate on a Maildir path.

*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.

I think you might be right that people might rely on this after having discovered this undocumented interaction by accident.

But I also think that the lack of questions about how to get imap-send's tunnel mode to work with auth helpers (at least I couldn't find any on-list), which is what you'd run into if you went by the documentation & were trying to get htat ot work, is a pretty good sign that this may be either entirely unused by anyone, or at best very obscure.

Show 7 quoted lines

> As I said, my main use of tunneling is to trigger the imap server's
> preauth mode. But there are other reasons one might want to do so, like
> piercing a firewall. E.g.:
>
>   [imap]
>   host = internal.example.com
>   tunnel = "ssh bastion-server nc internal.example.com 143"

I'll definitely leave this out of a re-roll of this topic, but I did come up with an opinionated replacement on top.

That commitdwhich rips out non-PREAUTH (i.e. any authentication) support, as well as SSL support that isn't using curl from git-imap-send.c.

Here: https://github.com/avar/git/commit/8498089f8e5a3d050b44008a7947ef3cefe2a2dd

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.

I.e. we'd support tunneling like this still (from the manpage):

	[imap]
		folder = "INBOX.Drafts"
		tunnel = "ssh -q -C user@example.com /usr/bin/imapd ./Maildir 2> /dev/null"

But if your use of imap.tunnel is to essentially use git-imap-send.c for what you could use another shell (or systemd or whatever) to invoke a "ssh" or "stunnel" command for you, we'd say too bad, just do that instead.

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"

Given the obscurity of git-imap-send overall, and how trivial the workaround is I don't think that's unreasonable, even with an aggressive transition period.

As that commit shows we have a surprising amount of code required to support just this one use-case (and I'm not even sure I got all of it). Or at least:

	7 files changed, 89 insertions(+), 509 deletions(-)

With most being OpenSSL library use, so if we can find a way to not keeping supporting that...