So tell me. Do you think #curl should support plain SSH:// URLs to execute commands remotely?
@bagder no, because I am a strong proponent of the UNIX principle. Curl does one thing great, let ssh do that other job.
can I also remind you all that curl already speaks SCP and SFTP, in command line tool and library...
@bagder adding 'ssh://' seems like it would introduce a fair amount of confusion. What features of an ssh client should curl itself implement? Does that implementation become some sort of ad hoc RPC protocol?
@bagder for me, that sounds like introducing a new kind of command line injection🫣
@bagder my impression is that the main scope of cURL is to fetch remote files (and push files to remotes that supports it).
From that point of view:
- support the SCP and SFTP protocols makes totally sense
- support remote execution of arbitrary command would fall under scope creep (and open too mant new cans of worms) (and also increase attack surface by giving opportunity for new creative abuse of the feature)
@bagder Hm, ssh can already to it: https://malcontentcomics.com/systemsboy/2006/07/send-remote-commands-via-ssh.html why mis-use curl then for this?
@bagder IMHO no; we have ssh already for that.
@bagder throw in a TUI and vim bindings while you're at it /s
and kids, don't forget that curl is even more a library than a command line tool...
@bagder this could be practical in a similar way to KDE's fish protocol. One could use cat or dd in case the server side lacks support for SCP or SFTP.
But generally it's really up to what people enjoy doing with the tool. I can write scripts that use wget and ssh just the same, so in this case it would really be the library use case where curl would stand out. In some cases this might really help to interact with embedded devices as which run a version of Dropbear without SCP and SFTP support.
@bagder curl can do POST http requests so seems like a fine addition
@bagder No, don't do it. We've got ssh for that.