On Fri, Feb 03 2023, Jeff King wrote: > On Thu, Feb 02, 2023 at 10:44:17AM +0100, Ævar Arnfjörð Bjarmason wrote: > >> 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@xxxxxxx /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...
