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.
> 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.
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. But that's
an even bigger task, and I not only wouldn't want to work on it, I'm not
even sure I'd want to review it. I'm slightly regretting getting
involved here at all, because it seems like none of us actually care at
all about imap-send, and this has turned into a big discussion. I mostly
chimed in because it seemed like I had a perspective you didn't on how
people might use tunnels, and it felt like I should speak up for folks
whose use cases might be getting broken.
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.
> 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"
Having done something like that before, the "arrange" step is more
finicky than you might think (because sometimes it goes away, and you
really want to trigger it on demand).
-Peff
