Advise request on adding a new SSH variant

Advise request on adding a new SSH variant

[Randall S. Becker]

Hi Team,

I am getting a bunch of requests from my team (and customers) to make SSH
configuration easier on the NonStop platform. We are currently using a
wrapper script to drive the variant of SSH on the platform but that is not
convenient for many people. I would like to add an ssh.Variant called
"nonstopssh", or something like that, which takes a few extra parameters.
-Q (quiet), -Z (don't display the banner), -p port (obvious but typically
required), -S (a system process name). The code in connect.c looks pretty
straight forward, but I'm wondering about the best way to pass in a process
name (it would be something like "$ZSSHX" - usually an environment variable
"SSH2_PROCESS_NAME"). The program name for SSH, I assume, could come from
GIT_SSH_COMMAND (typically "/G/system/zssh/sshoss", or I could force it if
not supplied). I'm also wondering about controls for the -Q and -Z
parameters. Should I just use the environment for this and build up args or
is there a more appropriate way of managing these values?

Thanks in advance,
Randall

-- Brief whoami:
NonStop developer since approximately 211288444200000000
UNIX developer since approximately 421664400
-- In my real life, I talk too much.

Re: Advise request on adding a new SSH variant

[Philip Oakley]

Hi Randall,
some drive-by comments..

On 26/04/2021 16:08, Randall S. Becker wrote:
> Hi Team,
>
> I am getting a bunch of requests from my team (and customers) to make SSH
> configuration easier on the NonStop platform. 
> We are currently using a
> wrapper script to drive the variant of SSH on the platform but that is not
> convenient for many people. 
> I would like to add an ssh.Variant called
> "nonstopssh", or something like that, which takes a few extra parameters.
> -Q (quiet), -Z (don't display the banner), -p port (obvious but typically
> required), -S (a system process name). 
https://git-scm.com/docs/git-config#Documentation/git-config.txt-sshvariant

Sounds sensible to me. Maybe also look at past issues that
Git-for-Windows had with folks having too much prior choice (plink,
putty, tortoiseplink). May need more clarity in the docs ;-)

> The code in connect.c looks pretty
> straight forward, but I'm wondering about the best way to pass in a process
> name (it would be something like "$ZSSHX" - usually an environment variable
> "SSH2_PROCESS_NAME"). 
Hopefully others can chime in.. Maybe see discussion at
<pull.913.git.1616511182942.gitgitgadget@gmail.com> about $ARG variable.
> The program name for SSH, I assume, could come from
> GIT_SSH_COMMAND (typically "/G/system/zssh/sshoss", or I could force it if
> not supplied). 
https://git-scm.com/docs/git-config#Documentation/git-config.txt-coresshCommand
> I'm also wondering about controls for the -Q and -Z
> parameters.
> Should I just use the environment for this and build up args or
> is there a more appropriate way of managing these values?

>
> Thanks in advance,
> Randall
>
> -- Brief whoami:
> NonStop developer since approximately 211288444200000000
> UNIX developer since approximately 421664400
> -- In my real life, I talk too much.
>
>
I was also thinking that the lack of replies maybe links to the "Pain
points in Git's patch flow" thread <YHaIBvl6Mf7ztJB3@google.com> whereby
it's all about the proposed patch, rather than thoughts about a
potential patch.
(Sort of like the philosophy of science [method] that ignores opinion,
and demands evidence)

--
Philip

RE: Advise request on adding a new SSH variant

[Randall S. Becker]

>From: <philipoakley@iee.email>
On May 4, 2021 10:45 AM, Philip Oakley wrote:
>On 26/04/2021 16:08, Randall S. Becker wrote:
>> I am getting a bunch of requests from my team (and customers) to make
>> SSH configuration easier on the NonStop platform.
>> We are currently using a
>> wrapper script to drive the variant of SSH on the platform but that is
>> not convenient for many people.
>> I would like to add an ssh.Variant called "nonstopssh", or something
>> like that, which takes a few extra parameters.
>> -Q (quiet), -Z (don't display the banner), -p port (obvious but
>> typically required), -S (a system process name).
>https://git-scm.com/docs/git-config#Documentation/git-config.txt-sshvariant
>
>Sounds sensible to me. Maybe also look at past issues that Git-for-Windows had
>with folks having too much prior choice (plink, putty, tortoiseplink). May need
>more clarity in the docs ;-)

In this situation, NonStop SSH is pretty much the only real option for users. OpenSSH works and is an option, but the version is lagging a due to port difficulties and $DAYJOB. NonStop SSH is supplied by the OS vendor, so basically everyone uses it.

>> The code in connect.c looks pretty
>> straight forward, but I'm wondering about the best way to pass in a
>> process name (it would be something like "$ZSSHX" - usually an
>> environment variable "SSH2_PROCESS_NAME").
>Hopefully others can chime in.. Maybe see discussion at
><pull.913.git.1616511182942.gitgitgadget@gmail.com> about $ARG variable.
>> The program name for SSH, I assume, could come from GIT_SSH_COMMAND
>> (typically "/G/system/zssh/sshoss", or I could force it if not
>> supplied).
>https://git-scm.com/docs/git-config#Documentation/git-config.txt-
>coresshCommand
>> I'm also wondering about controls for the -Q and -Z parameters.
>> Should I just use the environment for this and build up args or is
>> there a more appropriate way of managing these values?

The $ZSSHX form causes a shell started for GIT_SSH_COMMAND to have issues. Much cleaner to pass the value as a raw argument - rather the point of this variant. I'm trying to decide whether to put through V2, which removes controls for -Q and -Z, but I think it might be better to leave the patch as is. The $ prefix on process names goes back to 1978 (maybe before that in prototypes), and isn't going to change. I'm not sure the $ARG variable has any benefit here. The SSH2_PROCESS_NAME is going to be in the user's environment on that platform, so the default situation (just that variable), seems to do exactly what the end user needs. The other form of a process name is cluster node qualified, for example, \MYNODE.$ZSSHX, which makes things even worse in a shell because of the backslash *and* $. We otherwise end up with all sorts of junk in the end command, and errors with -S thinking the user name is a poorly formed process name.

-Randall

Re: Advise request on adding a new SSH variant

[Junio C Hamano]

Philip Oakley <philipoakley@iee.email> writes:

> I was also thinking that the lack of replies maybe links to the "Pain
> points in Git's patch flow" thread <YHaIBvl6Mf7ztJB3@google.com> whereby
> it's all about the proposed patch, rather than thoughts about a
> potential patch.
> (Sort of like the philosophy of science [method] that ignores opinion,
> and demands evidence)

Actually, the initial message on this matter from Randall came in
the patch form <011e01d73dd0$ec141530$c43c3f90$@nexbridge.com>, so
if it were truly "it's all about the proposed patch, rather than
thoughts about a potential patch", it would have gained much more
responses.

Other than I didn't have time, the reason I didn't respond was that
the concept and notation used there were a bit too foreign to me to
decide from where to start asking questions.  It wasn't clear what
'$ZSSHX' meant (is it the value of an environment variable whose
name is ZSSHX, or is it literally a name with dollar in it and is
the issue being addressed that it is too cumbersome to quote it
properly in value of the GIT_SSH_COMMAND environment variable?) for
example.  And after reading the message you are responding to twice,
I do not quite get what problem we are trying to solve.  Especially
since

    No, it would be GIT_SSH_COMMAND='/G/system/zssh/sshoss -Z -Q -S
    $ZSSH0' and that does not work correctly in the current git code
    base.

in <012601d73ddf$3d0cf660$b726e320$@nexbridge.com> sounded like we
have a fairly clearly demonstratable problem (i.e. the handling of
the command line given via GIT_SSH_COMMAND is somehow broken). The
details of "does not work correctly in the current code base" is not
yet disclosed but it sounded like it would be possible to tease it
out and solve the issue in a more direct way.  But yet the solution
presented in the three-patch series looked like it was sidestepping
the entire issue and adding a special case for NonStop without
having to touch GIT_SSH_COMMAND at all (presumably leaving it still
"broken").

RE: Advise request on adding a new SSH variant

[Randall S. Becker]

Randall S. Becker, Managing Director, Nexbridge Inc.
+1.416.984.9826

>-----Original Message-----
>From: Junio C Hamano <gitster@pobox.com>
>Sent: May 4, 2021 8:49 PM
>To: Philip Oakley <philipoakley@iee.email>
>Cc: Randall S. Becker <rsbecker@nexbridge.com>; git@vger.kernel.org
>Subject: Re: Advise request on adding a new SSH variant
>
>Philip Oakley <philipoakley@iee.email> writes:
>
>> I was also thinking that the lack of replies maybe links to the "Pain
>> points in Git's patch flow" thread <YHaIBvl6Mf7ztJB3@google.com>
>> whereby it's all about the proposed patch, rather than thoughts about
>> a potential patch.
>> (Sort of like the philosophy of science [method] that ignores opinion,
>> and demands evidence)
>
>Actually, the initial message on this matter from Randall came in the patch
form
><011e01d73dd0$ec141530$c43c3f90$@nexbridge.com>, so if it were truly "it's
>all about the proposed patch, rather than thoughts about a potential
patch", it
>would have gained much more responses.
>
>Other than I didn't have time, the reason I didn't respond was that the
concept
>and notation used there were a bit too foreign to me to decide from where
to
>start asking questions.  It wasn't clear what '$ZSSHX' meant (is it the
value of an
>environment variable whose name is ZSSHX, or is it literally a name with
dollar
>in it and is the issue being addressed that it is too cumbersome to quote
it
>properly in value of the GIT_SSH_COMMAND environment variable?) for
>example.  And after reading the message you are responding to twice, I do
not
>quite get what problem we are trying to solve.  Especially since
>
>    No, it would be GIT_SSH_COMMAND='/G/system/zssh/sshoss -Z -Q -S
>    $ZSSH0' and that does not work correctly in the current git code
>    base.
>
>in <012601d73ddf$3d0cf660$b726e320$@nexbridge.com> sounded like we
>have a fairly clearly demonstratable problem (i.e. the handling of the
command
>line given via GIT_SSH_COMMAND is somehow broken). The details of "does not
>work correctly in the current code base" is not yet disclosed but it
sounded like it
>would be possible to tease it out and solve the issue in a more direct way.
But
>yet the solution presented in the three-patch series looked like it was
>sidestepping the entire issue and adding a special case for NonStop without
>having to touch GIT_SSH_COMMAND at all (presumably leaving it still
"broken").

Were it not for the response in thread
https://public-inbox.org/git/008101d4f3db$56c20410$04460c30$@nexbridge.com,
I would take a 100% agreement position. But it sounded like the problem was
platform-related so would not be fixed, thus the variant that avoids the
issue.

By running a shell if GIT_SSH_COMMAND is not a simple path, with potentially
multiple levels of escapes of the $ required, depending on the circumstances
of how the command is run, I would agree completely. However, with a
variant, as described in how the variant operates (from my interpretation),
it seems like the approach of the patch is correct by avoiding shell
variable resolution on an exotic platform rather than solving an otherwise
situation that would not be likely to occur anywhere else.

The environment variable is named SSH2_PROCESS_NAME and contains a value
starting with $ - making a shell interpret it if a shell is started. $ZSSH0
is a typical name used, but the value varies from system to system, except
for the $ that is mandatory to designate the name of a process. There was no
UNIX variant in 1978 when the platform was created, so that prefix character
was chosen. It won't change in the foreseeable future, for the expected
lifespan of the platform.

With all of the above, as long as there is a potential solution, I'm up for
it, but let me know how you would like it to look and I'll try to make it
work.

-Randall "who did not himself come up with the NonStop naming structure" and
"who has no control over how NonStop SSH interprets anything whatsoever"
Becker.

Re: Advise request on adding a new SSH variant

[Philip Oakley]

On 05/05/2021 01:49, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.email> writes:
>
>> I was also thinking that the lack of replies maybe links to the "Pain
>> points in Git's patch flow" thread <YHaIBvl6Mf7ztJB3@google.com> whereby
>> it's all about the proposed patch, rather than thoughts about a
>> potential patch.
>> (Sort of like the philosophy of science [method] that ignores opinion,
>> and demands evidence)
> Actually, the initial message on this matter from Randall came in
> the patch form <011e01d73dd0$ec141530$c43c3f90$@nexbridge.com>, so
> if it were truly "it's all about the proposed patch, rather than
> thoughts about a potential patch", it would have gained much more
> responses.

I'd missed the patches (at the time) as my mail client hadn't grouped
them together, so that mail looked a bit lonely, hence my reply ;-)
I saw a later note by Randall that send-email hadn't worked on his
system which gave rise to the patches being 'spread about'.
>
> Other than I didn't have time, the reason I didn't respond was that
> the concept and notation used there were a bit too foreign to me to
> decide from where to start asking questions.  It wasn't clear what
> '$ZSSHX' meant (is it the value of an environment variable whose
> name is ZSSHX, or is it literally a name with dollar in it and is
> the issue being addressed that it is too cumbersome to quote it
> properly in value of the GIT_SSH_COMMAND environment variable?) for
> example.  And after reading the message you are responding to twice,
> I do not quite get what problem we are trying to solve.  Especially
> since
>
>     No, it would be GIT_SSH_COMMAND='/G/system/zssh/sshoss -Z -Q -S
>     $ZSSH0' and that does not work correctly in the current git code
>     base.
>
> in <012601d73ddf$3d0cf660$b726e320$@nexbridge.com> sounded like we
> have a fairly clearly demonstratable problem (i.e. the handling of
> the command line given via GIT_SSH_COMMAND is somehow broken). The
> details of "does not work correctly in the current code base" is not
> yet disclosed but it sounded like it would be possible to tease it
> out and solve the issue in a more direct way.  But yet the solution
> presented in the three-patch series looked like it was sidestepping
> the entire issue and adding a special case for NonStop without
> having to touch GIT_SSH_COMMAND at all (presumably leaving it still
> "broken").
I didn't understand all that either. I'd just spotted the other ssh
variants being common on Windows.. A classic curse of knowledge (or lack
of it) problem.

Philip