3 ms·

OpenSSH has already added plenty of extensions and the world seems to be fairly comfortable with using quite a few of them - for backwards compatibility reasons

by mst 3y ago

OpenSSH has already added plenty of extensions and the world seems to be fairly comfortable with using quite a few of them - for backwards compatibility reasons they probably can't change the current behaviour by default for -everybody- but a protocol extension and a flag to use it would improve the world substantially.

rollcat 3y ago
The current behaviour is already a UX trap, and such an extension would be another one on top of it. What's the sane thing to do if either end does not support it? Any kind of fallback would just make things even worse; detecting and supporting both variants is a road to hell. I still have CentOS 7 systems in production, with the last CentOS 6 box only decommissioned a few years ago. Judo mostly works because it sticks with the lowest common denominator, the value comes from things you can do on top of it.
- saltcured 3y ago
  What's interesting to me is that this "UX trap" is of ancient origin not mentioned in any post that I could find here. The whole ssh CLI started off trying to mimic the existing rsh CLI experience for basic things, just as scp tried to mimic rcp. To me, this is a bit like the scp vs sftp topic. You really want a new remote-invocation CLI that throws away the rsh compatibility concept and is designed with "modern" goals. And, it probably needs new protocol elements to properly engineer it. But this is also similar to the "system" callouts from multiple languages which abdicate responsibility and pass a command string to an external interpreter. Are all these API designers so naive, or do they have a philosophy of being so inclusive that they are not willing to assume that a command on a target system involves an executable and an array of arguments?
  - rollcat 3y ago
    > Are all these API designers so naive, or do they have a philosophy of being so inclusive that they are not willing to assume that a command on a target system involves an executable and an array of arguments? Remember APIs are made for humans, (assuming we're talking local processes) nobody can stop you from using raw fork(2)+pipe(2)+execve(2) every time, yet you will usually reach for popen(3).
- formerly_proven 3y ago
  Add a flag or option to the client, e.g. -oSplitExec=true or -E* or whatever. This then uses an execv request type or something like that. If the server does not understand that, this is an error. OpenSSH updates tend to be rolled out very slowly though. So if you wanted any kind of widespread usability of this option, you would've needed to add this about ten years ago. * this is of course alreay taken, it seems only -u and -z are free at this point. You could use -U and pretend to be a roman (EXECUE).

by mst 3y ago

rollcat 3y ago

The current behaviour is already a UX trap, and such an extension would be another one on top of it. What's the sane thing to do if either end does not support it? Any kind of fallback would just make things even worse; detecting and supporting both variants is a road to hell. I still have CentOS 7 systems in production, with the last CentOS 6 box only decommissioned a few years ago. Judo mostly works because it sticks with the lowest common denominator, the value comes from things you can do on top of it.

saltcured 3y ago
What's interesting to me is that this "UX trap" is of ancient origin not mentioned in any post that I could find here. The whole ssh CLI started off trying to mimic the existing rsh CLI experience for basic things, just as scp tried to mimic rcp. To me, this is a bit like the scp vs sftp topic. You really want a new remote-invocation CLI that throws away the rsh compatibility concept and is designed with "modern" goals. And, it probably needs new protocol elements to properly engineer it. But this is also similar to the "system" callouts from multiple languages which abdicate responsibility and pass a command string to an external interpreter. Are all these API designers so naive, or do they have a philosophy of being so inclusive that they are not willing to assume that a command on a target system involves an executable and an array of arguments?
- rollcat 3y ago
  > Are all these API designers so naive, or do they have a philosophy of being so inclusive that they are not willing to assume that a command on a target system involves an executable and an array of arguments? Remember APIs are made for humans, (assuming we're talking local processes) nobody can stop you from using raw fork(2)+pipe(2)+execve(2) every time, yet you will usually reach for popen(3).
formerly_proven 3y ago
Add a flag or option to the client, e.g. -oSplitExec=true or -E* or whatever. This then uses an execv request type or something like that. If the server does not understand that, this is an error. OpenSSH updates tend to be rolled out very slowly though. So if you wanted any kind of widespread usability of this option, you would've needed to add this about ten years ago. * this is of course alreay taken, it seems only -u and -z are free at this point. You could use -U and pretend to be a roman (EXECUE).