On Tue, Feb 07 2023, Jeff King wrote:
> 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.
> 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@xxxxxxxxxxx /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...
