So tell me. Do you think #curl should support plain SSH:// URLs to execute commands remotely?
@bagder Please don't.
Random slopware shouldn't be given the oppurtinity to abuse libcurl to execute remote commands…
Because people WILL install random slopware on their computers, get their credentials stolen and servers compromised, then complain how "curl is insecure" if the actual software that caused the issue in the first place, happens to use libcurl…
@bagder Please don't.
Random slopware shouldn't be given the oppurtinity to abuse libcurl to execute remote commands…
@bagder this sounds like asking for trouble
@bagder Is there even a standard for SSH:// urls? First time seeing it in the wild.
@bagder if only there would be a command line program and a C library, to communicate with ssh servers, then curl wont have to....
@icing @catsalad @bagder clown activity aside, I'm really imagining this as being a fun feature for malicious actors to dodge environment restrictions rather than being used as a normally useful tool. Like it would be a neat party trick to execute commands. But that's what other tools are explicitly designed for, and they would probably be less awkward to use for normal use cases
@tehfishman @catsalad @bagder Yeah, the whole team feels this way. I believe Daniel want to give everyone the option to chime in with some positive aspect that we overlooked.
@bagder I’d only allow that in the cli. If a user can execute the command “curl” it could be ok, though if it is executed in a different context (e.g. when calling curl library functions as a dependency), it could create unexpected security risks.
@bagder I think curl should not support this.
I am open to an argument that the curl library offers so much high value scaffolding around the raw SSH protocol that adding remote execution seems like a small complexity addition with a potentially large benefit.
But curl is mainly written as a tool for uploading and downloading data transactionally. A remote execution mechanism might fit the implementation & design now, opportunistically, but could easily become a poorer fit during redesigns.
@bagder
scope creep IMO
Next thing you know, someone will want to pass LANG or TERM env var to the executed command, or allocate a tty.
@bagder I mean, It's inevitable. Isn't it? 😉
@bagder No.
Even less so when it's slop.
@bagder Unless it requires command line arguments to indicate this is not a pure document request, no. Just like a GET should not act as a POST, buy 1000000x worse.
Also where would it be getting the credentials? Would curl/libcurl snoop your .ssh??
@dalias curl already does SCP and SFTP with credentials, so that's not really a new problem. But yeah, I don't feel that SSH has a good story for curl.
@bagder Nah, just sounds like another cluster of problems.