On 2024/12/17 06:19:49 +0100, Stefan Sperling <stsp@stsp.name> wrote:
> On Wed, Dec 11, 2024 at 10:37:54PM +0000, Lucas Gabriel Vuotto wrote:
> > On Wed, Dec 11, 2024 at 09:33:54PM +0100, Stefan Sperling wrote:
> > > On Wed, Dec 11, 2024 at 09:31:32PM +0100, Stefan Sperling wrote:
> > > > On Wed, Dec 11, 2024 at 06:27:53PM +0000, Lucas Gabriel Vuotto wrote:
> > > > > On Wed, Dec 11, 2024 at 06:13:59PM +0100, Stefan Sperling wrote:
> > > > > > Add a -J option to got clone, fetch, send, as well as cvg clone,
> > > > > > update, commit. This allows ad-hoc use of SSH jumphosts without
> > > > > > having to create entries in ~/.ssh/config.
> > > > > > 
> > > > > > For example, I found this useful when I wanted to fetch from a
> > > > > > IPv6-only system while borrowing an IPv4-only wifi connection.
> > > > > > 
> > > > > > ok?
> > > > > 
> > > > > I don't know about the potential complexity, but wouldn't it be better
> > > > > to have an ssh_opts in got.conf instead? Having a dedicated flag for
> > > > > ProxyJump feels off for me.
> > > > 
> > > > But that would involve editing a configuration file, too. The point
> > > > is avoid that overhead when reaching the configured remote without
> > > > a jumphost or vpn or whatever is impossible.
> > > 
> > > And adding ssh_opts to got.conf would be no different to the current
> > > way of setting per-remote ssh options, which is to add a Host entry
> > > to ~/.ssh/config with whatever options are requried and using that
> > > Host entry as the server URL.
> > 
> > I'd argue it's slightly different, because the remote block already
> > exists in got.conf, and the scope is exclusively for got operations.
> > 
> > Alternatively, I believe that the Git way is GIT_SSH_COMMAND, which
> > also seems more reasonable to me than adding -J to a bunch of
> > subcommands.
> 
> It's only 3 subcommands, specifically those which use openssh to
> talk to the network.

Makes sense to me to add -J (or equivalent.)  This maybe doesn't rule
out having an option on got.conf, option on which I don't have a strong
opinion, but having the freedom to quickly pass through a jumphost seems
nice enough to warrants a new flag.

> Git also supports other ssh implementations such as putty which use a
> different set of command line options. Which is something we don't have
> to worry about because we can expect openssh to be present on unix-style
> systems. We don't need an abstraction that hides openssh from our UI.
> Rather, tighter integration with openssh seems natural to me since our
> network layer is openssh (ignoring our minimal HTTP support, which only
> exists because most forges don't offer anonssh for public access).

also makes sense to me; we should try to keep things simple rather than
aim for infinite support.

> > Alternatively, maybe a -o blah, with blah passed verbatim to ssh -o.
> > 
> > Anyways, this is a non-blocking opinion. I consider a dedicated
> > ProxyJump limiting (what if I need ProxyCommand instead?) and the
> > possiblity for something more generic, without dealing with ssh_config,
> > is there, quite at hand. (I concede that got send -oproxyjump=6to4 $r
> > doesn't looks as slick as got send -J 6to4 $r).
> 
> The -o option might be useful at times, but most of these options control
> settings of a more permanent nature, such as use of allowed obsolete ciphers.
> ProxyJump/-J can be used as an ad-hoc workaround for momentary issues with
> the local network, much like -4 or -6.

fwiw I agree.  passing arbitrary arguments to ssh(1) is outside of the
scope for a wrapping utility like `got send'.  Not sure it warrants the
extra complexity either.

> By your reasoning, should ssh itself have a -J option?
> While ssh(1) offers -J as a shortcut for ProxyJump, it does not offer such
> a shortcut for ProxyCommand.
> 
> We can make other useful ssh options reachable via got's interface,
> provided the option letters don't overlap.
> Other useful options might be: -4, -6, -f, -F, -I, -i, -K, -S
> Except for -f used by 'git send', all of these options could still be
> allocated to got clone/fetch/send. I guess we can live without ssh -f?

not sure how many of these are actually useful (thinking in particular
of [fIiKS].)  folks can use custom configuration in their ~/.ssh/config
for them.  I might be convinced about -F, in some situations I've used
an alternate configuration file and that could indeed be handy as well.
my two cents :)