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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 8, 2023, 01:06 UTC
Message-ID: <230208.86a61p0x9n.gmgdl@evledraar.gmail.com>
In-Reply-To: <Y+LNitGAude1vogv@coredump.intra.peff.net>

On Tue, Feb 07 2023, Jeff King wrote:

Show 9 quoted lines

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

*nod*

Show 11 quoted lines

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

Makes sense.

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

I really think it's obscure enough that just offerng users a documented way out should be neough.

Show 7 quoted lines

> [...]
>   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.

I think it's a reasonable feature, but in hindsight our mistake was to think that we should be perma-forking isync, which has since moved on. I've used isync's "mbsync" extensively for IMAP in other contexts, and it works well for that.

So if we were going back to the drawing board a "git-imap-sync" really should just be something in our mail tooling that can produce a Maildir, and if we wanted an IMAP helper it could invoke mbsync, offlineimap or various other "maildir to IMAP" bidirectional syncing utilities to "send" via IMAP.

So, just some hook support for format-patch with some documented examples should do it, but I won't be working on that task...