On Fri, Feb 03 2023, Jeff King wrote:
On Thu, Feb 02, 2023 at 10:44:17AM +0100, Ævar Arnfjörð Bjarmason wrote:
quoted
Before [1] we'd force the "imap.host" to be set, even if the
"imap.tunnel" was set, and then proceed to not use the "host" for
establishing a connection, as we'd use the tunneling command.
However, we'd still use the "imap.host" if it was set as the "host"
field given to the credential helper, and in messages that were shared
with the non-tunnel mode, until a preceding commit made these OpenSSL
codepaths tunnel-only.
Let's always give "host=tunnel" to the credential helper when in the
"imap.tunnel" mode, and rephrase the relevant messages to indicate
that we're tunneling. This changes the existing behavior, but that
behavior was emergent and didn't make much sense. If we were using
"imap.tunnel" the value in "imap.host" might be entirely unrelated to
the host we're tunneling to. Let's not pretend to know more than we do
in that case.
If you tunnel to two different hosts, how is the credential system
supposed to know which is which?
If you really want to distinguish connecting to $host versus tunneling
to $host, I think you'd have to invent some new URL scheme
(imap-tunnel:// or something).
But IMHO it is not really worth it. Your statement of "the value in
imap.host might be entirely unrelated" does not match my experience. I
don't use imap-send, but I've been doing imap-tunneling with various
programs for two decades, and it's pretty normal to configure both, and
to consider the tunnel command as an implementation detail for getting
to the host. For example, my mutt config is like[1]:
set folder = imap://example.com/
set tunnel = "ssh example.com /etc/rimapd"
and I expect to be able to refer to folders as imap://example.com/foo,
etc (well, in mutt you'd use the shorthand "=foo", but the idea is the
same). So if we see:
[imap]
host = example.com
tunnel = ssh example.com /etc/rimapd
we should likewise think of it as example.com, but with an
implementation detail of how to contact the server.
Except that mutt config is different than the imap-send case in that it
would presumably break if you changed:
set folder = imap://example.com/
set tunnel = "ssh example.com /etc/rimapd"
So that one of the two was example.org instead of example.com (or
whatever).
I agree that "give this to the auth helper" might be useful in general,
but our current documentation says:
To use the tool, `imap.folder` and either `imap.tunnel` or `imap.host` must be set
to appropriate values.
And the docs for "imap.tunnel" say "Required when imap.host is not set",
and "imap.host" says "Ignored when imap.tunnel is set, but required
otherwise".
Perhaps we should bless this as an accidental feature instead of my
proposed patch, but that's why I made this change. It seemed like an
unintentional bug that nobody intended.
Especially as you're focusing on the case where it contrary to the docs
would do what you mean, but consider (same as the doc examples, but the
domains are changed):
[imap]
folder = "INBOX.Drafts"
host = imap://imap.bar.com
user = bob
pass = p4ssw0rd
[imap]
folder = "INBOX.Drafts"
tunnel = "ssh -q -C user@foo.com /usr/bin/imapd ./Maildir 2> /dev/null"
I.e. I have a config for "bar.com" I tried earlier, but now I'm trying
to connect to "foo.com", because I read the docs and notice it prefers
"tunnel" to "host" I think it's going to ignore that "imap.host", but
it's going to provide the password for bar.com to foo.com if challenged.
So I think if we want to keep this it would be better to have a
imap.tunnel.credentialHost or something, to avoid conflating the two.
But I think it's okey to just remove this until someone has this
explicit use-case. I doubt that we have any users relying on this, as
it's not only undocumented, but the documentation explicitly states that
it doesn't work like this.
Of course if you don't set imap.host, then we don't have anything useful
to say. But as you saw, in that case imap-send will default the host
field to the word "tunnel".
Isn't that more of a suggestion that nobody cares about this? Presumably
if we had users trying to get this to work someone would have complained
that they wanted a custom string rather than "tunnel", as the auth
helper isn't very helpful in that case...