{"thread":{"id":"55561","subject":"Advise request on adding a new SSH variant","startedAt":"2021-04-26T15:08:32Z","lastAt":"2021-05-05T10:49:27Z","messageCount":6,"participants":["Randall S. Becker","Philip Oakley","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"422932","messageId":"043101d73aae$026409b0$072c1d10$@nexbridge.com","threadId":"55561","inReplyTo":null,"subject":"Advise request on adding a new SSH variant","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-04-26T15:08:21Z","receivedAt":"2021-04-26T15:08:32Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"Hi Team,\n\nI am getting a bunch of requests from my team (and customers) to make SSH\nconfiguration easier on the NonStop platform. We are currently using a\nwrapper script to drive the variant of SSH on the platform but that is not\nconvenient for many people. I would like to add an ssh.Variant called\n\"nonstopssh\", or something like that, which takes a few extra parameters.\n-Q (quiet), -Z (don't display the banner), -p port (obvious but typically\nrequired), -S (a system process name). The code in connect.c looks pretty\nstraight forward, but I'm wondering about the best way to pass in a process\nname (it would be something like \"$ZSSHX\" - usually an environment variable\n\"SSH2_PROCESS_NAME\"). The program name for SSH, I assume, could come from\nGIT_SSH_COMMAND (typically \"/G/system/zssh/sshoss\", or I could force it if\nnot supplied). I'm also wondering about controls for the -Q and -Z\nparameters. Should I just use the environment for this and build up args or\nis there a more appropriate way of managing these values?\n\nThanks in advance,\nRandall\n\n-- Brief whoami:\nNonStop developer since approximately 211288444200000000\nUNIX developer since approximately 421664400\n-- In my real life, I talk too much.\n\n\n"},{"id":"423578","messageId":"fa8f81db-d470-130e-115d-7aef5e97e5a7@iee.email","threadId":"55561","inReplyTo":"043101d73aae$026409b0$072c1d10$@nexbridge.com","subject":"Re: Advise request on adding a new SSH variant","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-04T14:45:00Z","receivedAt":"2021-05-04T14:45:03Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Randall,\nsome drive-by comments..\n\nOn 26/04/2021 16:08, Randall S. Becker wrote:\n> Hi Team,\n>\n> I am getting a bunch of requests from my team (and customers) to make SSH\n> configuration easier on the NonStop platform. \n> We are currently using a\n> wrapper script to drive the variant of SSH on the platform but that is not\n> convenient for many people. \n> I would like to add an ssh.Variant called\n> \"nonstopssh\", or something like that, which takes a few extra parameters.\n> -Q (quiet), -Z (don't display the banner), -p port (obvious but typically\n> required), -S (a system process name). \nhttps://git-scm.com/docs/git-config#Documentation/git-config.txt-sshvariant\n\nSounds sensible to me. Maybe also look at past issues that\nGit-for-Windows had with folks having too much prior choice (plink,\nputty, tortoiseplink). May need more clarity in the docs ;-)\n\n> The code in connect.c looks pretty\n> straight forward, but I'm wondering about the best way to pass in a process\n> name (it would be something like \"$ZSSHX\" - usually an environment variable\n> \"SSH2_PROCESS_NAME\"). \nHopefully others can chime in.. Maybe see discussion at\n about $ARG variable.\n> The program name for SSH, I assume, could come from\n> GIT_SSH_COMMAND (typically \"/G/system/zssh/sshoss\", or I could force it if\n> not supplied). \nhttps://git-scm.com/docs/git-config#Documentation/git-config.txt-coresshCommand\n> I'm also wondering about controls for the -Q and -Z\n> parameters.\n> Should I just use the environment for this and build up args or\n> is there a more appropriate way of managing these values?\n\n>\n> Thanks in advance,\n> Randall\n>\n> -- Brief whoami:\n> NonStop developer since approximately 211288444200000000\n> UNIX developer since approximately 421664400\n> -- In my real life, I talk too much.\n>\n>\nI was also thinking that the lack of replies maybe links to the \"Pain\npoints in Git's patch flow\" thread whereby\nit's all about the proposed patch, rather than thoughts about a\npotential patch.\n(Sort of like the philosophy of science [method] that ignores opinion,\nand demands evidence)\n\n--\nPhilip\n"},{"id":"423581","messageId":"004401d740f9$b3112a80$19337f80$@nexbridge.com","threadId":"55561","inReplyTo":"fa8f81db-d470-130e-115d-7aef5e97e5a7@iee.email","subject":"RE: Advise request on adding a new SSH variant","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-05-04T15:25:16Z","receivedAt":"2021-05-04T15:25:34Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":">From: \nOn May 4, 2021 10:45 AM, Philip Oakley wrote:\n>On 26/04/2021 16:08, Randall S. Becker wrote:\n>> I am getting a bunch of requests from my team (and customers) to make\n>> SSH configuration easier on the NonStop platform.\n>> We are currently using a\n>> wrapper script to drive the variant of SSH on the platform but that is\n>> not convenient for many people.\n>> I would like to add an ssh.Variant called \"nonstopssh\", or something\n>> like that, which takes a few extra parameters.\n>> -Q (quiet), -Z (don't display the banner), -p port (obvious but\n>> typically required), -S (a system process name).\n>https://git-scm.com/docs/git-config#Documentation/git-config.txt-sshvariant\n>\n>Sounds sensible to me. Maybe also look at past issues that Git-for-Windows had\n>with folks having too much prior choice (plink, putty, tortoiseplink). May need\n>more clarity in the docs ;-)\n\nIn 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.\n\n>> The code in connect.c looks pretty\n>> straight forward, but I'm wondering about the best way to pass in a\n>> process name (it would be something like \"$ZSSHX\" - usually an\n>> environment variable \"SSH2_PROCESS_NAME\").\n>Hopefully others can chime in.. Maybe see discussion at\n> about $ARG variable.\n>> The program name for SSH, I assume, could come from GIT_SSH_COMMAND\n>> (typically \"/G/system/zssh/sshoss\", or I could force it if not\n>> supplied).\n>https://git-scm.com/docs/git-config#Documentation/git-config.txt-\n>coresshCommand\n>> I'm also wondering about controls for the -Q and -Z parameters.\n>> Should I just use the environment for this and build up args or is\n>> there a more appropriate way of managing these values?\n\nThe $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.\n\n-Randall\n\n"},{"id":"423628","messageId":"xmqqlf8u57jl.fsf@gitster.g","threadId":"55561","inReplyTo":"fa8f81db-d470-130e-115d-7aef5e97e5a7@iee.email","subject":"Re: Advise request on adding a new SSH variant","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-05T00:49:18Z","receivedAt":"2021-05-05T00:49:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> I was also thinking that the lack of replies maybe links to the \"Pain\n> points in Git's patch flow\" thread whereby\n> it's all about the proposed patch, rather than thoughts about a\n> potential patch.\n> (Sort of like the philosophy of science [method] that ignores opinion,\n> and demands evidence)\n\nActually, the initial message on this matter from Randall came in\nthe patch form <011e01d73dd0$ec141530$c43c3f90$@nexbridge.com>, so\nif it were truly \"it's all about the proposed patch, rather than\nthoughts about a potential patch\", it would have gained much more\nresponses.\n\nOther than I didn't have time, the reason I didn't respond was that\nthe concept and notation used there were a bit too foreign to me to\ndecide from where to start asking questions. It wasn't clear what\n'$ZSSHX' meant (is it the value of an environment variable whose\nname is ZSSHX, or is it literally a name with dollar in it and is\nthe issue being addressed that it is too cumbersome to quote it\nproperly in value of the GIT_SSH_COMMAND environment variable?) for\nexample. And after reading the message you are responding to twice,\nI do not quite get what problem we are trying to solve. Especially\nsince\n\n No, it would be GIT_SSH_COMMAND='/G/system/zssh/sshoss -Z -Q -S\n $ZSSH0' and that does not work correctly in the current git code\n base.\n\nin <012601d73ddf$3d0cf660$b726e320$@nexbridge.com> sounded like we\nhave a fairly clearly demonstratable problem (i.e. the handling of\nthe command line given via GIT_SSH_COMMAND is somehow broken). The\ndetails of \"does not work correctly in the current code base\" is not\nyet disclosed but it sounded like it would be possible to tease it\nout and solve the issue in a more direct way. But yet the solution\npresented in the three-patch series looked like it was sidestepping\nthe entire issue and adding a special case for NonStop without\nhaving to touch GIT_SSH_COMMAND at all (presumably leaving it still\n\"broken\").\n"},{"id":"423635","messageId":"008b01d74152$f68eb3f0$e3ac1bd0$@nexbridge.com","threadId":"55561","inReplyTo":"xmqqlf8u57jl.fsf@gitster.g","subject":"RE: Advise request on adding a new SSH variant","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-05-05T02:04:15Z","receivedAt":"2021-05-05T02:04:35Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"\n\nRandall S. Becker, Managing Director, Nexbridge Inc.\n+1.416.984.9826\n\n>-----Original Message-----\n>From: Junio C Hamano \n>Sent: May 4, 2021 8:49 PM\n>To: Philip Oakley \n>Cc: Randall S. Becker ; git@vger.kernel.org\n>Subject: Re: Advise request on adding a new SSH variant\n>\n>Philip Oakley writes:\n>\n>> I was also thinking that the lack of replies maybe links to the \"Pain\n>> points in Git's patch flow\" thread \n>> whereby it's all about the proposed patch, rather than thoughts about\n>> a potential patch.\n>> (Sort of like the philosophy of science [method] that ignores opinion,\n>> and demands evidence)\n>\n>Actually, the initial message on this matter from Randall came in the patch\nform\n><011e01d73dd0$ec141530$c43c3f90$@nexbridge.com>, so if it were truly \"it's\n>all about the proposed patch, rather than thoughts about a potential\npatch\", it\n>would have gained much more responses.\n>\n>Other than I didn't have time, the reason I didn't respond was that the\nconcept\n>and notation used there were a bit too foreign to me to decide from where\nto\n>start asking questions. It wasn't clear what '$ZSSHX' meant (is it the\nvalue of an\n>environment variable whose name is ZSSHX, or is it literally a name with\ndollar\n>in it and is the issue being addressed that it is too cumbersome to quote\nit\n>properly in value of the GIT_SSH_COMMAND environment variable?) for\n>example. And after reading the message you are responding to twice, I do\nnot\n>quite get what problem we are trying to solve. Especially since\n>\n> No, it would be GIT_SSH_COMMAND='/G/system/zssh/sshoss -Z -Q -S\n> $ZSSH0' and that does not work correctly in the current git code\n> base.\n>\n>in <012601d73ddf$3d0cf660$b726e320$@nexbridge.com> sounded like we\n>have a fairly clearly demonstratable problem (i.e. the handling of the\ncommand\n>line given via GIT_SSH_COMMAND is somehow broken). The details of \"does not\n>work correctly in the current code base\" is not yet disclosed but it\nsounded like it\n>would be possible to tease it out and solve the issue in a more direct way.\nBut\n>yet the solution presented in the three-patch series looked like it was\n>sidestepping the entire issue and adding a special case for NonStop without\n>having to touch GIT_SSH_COMMAND at all (presumably leaving it still\n\"broken\").\n\nWere it not for the response in thread\nhttps://public-inbox.org/git/008101d4f3db$56c20410$04460c30$@nexbridge.com,\nI would take a 100% agreement position. But it sounded like the problem was\nplatform-related so would not be fixed, thus the variant that avoids the\nissue.\n\nBy running a shell if GIT_SSH_COMMAND is not a simple path, with potentially\nmultiple levels of escapes of the $ required, depending on the circumstances\nof how the command is run, I would agree completely. However, with a\nvariant, as described in how the variant operates (from my interpretation),\nit seems like the approach of the patch is correct by avoiding shell\nvariable resolution on an exotic platform rather than solving an otherwise\nsituation that would not be likely to occur anywhere else.\n\nThe environment variable is named SSH2_PROCESS_NAME and contains a value\nstarting with $ - making a shell interpret it if a shell is started. $ZSSH0\nis a typical name used, but the value varies from system to system, except\nfor the $ that is mandatory to designate the name of a process. There was no\nUNIX variant in 1978 when the platform was created, so that prefix character\nwas chosen. It won't change in the foreseeable future, for the expected\nlifespan of the platform.\n\nWith all of the above, as long as there is a potential solution, I'm up for\nit, but let me know how you would like it to look and I'll try to make it\nwork.\n\n-Randall \"who did not himself come up with the NonStop naming structure\" and\n\"who has no control over how NonStop SSH interprets anything whatsoever\"\nBecker.\n\n\n"},{"id":"423651","messageId":"6bde927d-19da-a350-825b-b8bf71d19269@iee.email","threadId":"55561","inReplyTo":"xmqqlf8u57jl.fsf@gitster.g","subject":"Re: Advise request on adding a new SSH variant","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-05T10:49:20Z","receivedAt":"2021-05-05T10:49:27Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 05/05/2021 01:49, Junio C Hamano wrote:\n> Philip Oakley writes:\n>\n>> I was also thinking that the lack of replies maybe links to the \"Pain\n>> points in Git's patch flow\" thread whereby\n>> it's all about the proposed patch, rather than thoughts about a\n>> potential patch.\n>> (Sort of like the philosophy of science [method] that ignores opinion,\n>> and demands evidence)\n> Actually, the initial message on this matter from Randall came in\n> the patch form <011e01d73dd0$ec141530$c43c3f90$@nexbridge.com>, so\n> if it were truly \"it's all about the proposed patch, rather than\n> thoughts about a potential patch\", it would have gained much more\n> responses.\n\nI'd missed the patches (at the time) as my mail client hadn't grouped\nthem together, so that mail looked a bit lonely, hence my reply ;-)\nI saw a later note by Randall that send-email hadn't worked on his\nsystem which gave rise to the patches being 'spread about'.\n>\n> Other than I didn't have time, the reason I didn't respond was that\n> the concept and notation used there were a bit too foreign to me to\n> decide from where to start asking questions. It wasn't clear what\n> '$ZSSHX' meant (is it the value of an environment variable whose\n> name is ZSSHX, or is it literally a name with dollar in it and is\n> the issue being addressed that it is too cumbersome to quote it\n> properly in value of the GIT_SSH_COMMAND environment variable?) for\n> example. And after reading the message you are responding to twice,\n> I do not quite get what problem we are trying to solve. Especially\n> since\n>\n> No, it would be GIT_SSH_COMMAND='/G/system/zssh/sshoss -Z -Q -S\n> $ZSSH0' and that does not work correctly in the current git code\n> base.\n>\n> in <012601d73ddf$3d0cf660$b726e320$@nexbridge.com> sounded like we\n> have a fairly clearly demonstratable problem (i.e. the handling of\n> the command line given via GIT_SSH_COMMAND is somehow broken). The\n> details of \"does not work correctly in the current code base\" is not\n> yet disclosed but it sounded like it would be possible to tease it\n> out and solve the issue in a more direct way. But yet the solution\n> presented in the three-patch series looked like it was sidestepping\n> the entire issue and adding a special case for NonStop without\n> having to touch GIT_SSH_COMMAND at all (presumably leaving it still\n> \"broken\").\nI didn't understand all that either. I'd just spotted the other ssh\nvariants being common on Windows.. A classic curse of knowledge (or lack\nof it) problem.\n\nPhilip\n"}]}