-
Notifications
You must be signed in to change notification settings - Fork 255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: Proper shellescaping missing #283
Comments
Unless it's provably perfect (hint: it isn't) What was the concrete issue you had? |
I don't understand. Why? You care enough to escape environment variables…
We execute commands with parameters provided by the user or certain configuration. On of the parameter contained a ampersand Pseudo code:
What gets executed:
|
@ncreuschling I'm not sure if you still have a vested interest in this, lots of time has gone by. I'm closing the issue because there's no proper way for us to do shell escaping and guarantee that it behaves the way people expect. Escaping of ENV vars was probably a mistake too. I'm sure you can acknowledge that any change to this will leave Capistrano in a better state for some, but a worse state for others. If you need your input to be escaped, or are using Capistrano with untrusted inputs, you might better address it in your own code, as I'm sure you've already had to do. I'm sure we could compromise on a warning if something is not shell escaped, but then making it possible to disable the warning, globally, or on a per-call basis adds more complexity to the DSL API that I don't see a neat solution for just now. String#tainted springs to mind, but I believe the feature to be too obscure to be widely acceptable as a useful solution. See #333 |
Obsoleted by #333 |
We recently ran into a problem with unescaped shell commands via
execute
.I think, shellescaping with Ruby's built-in method has been removed due to #10 in version 1.5.0. It is my understanding, sshkit does not shellescape any command at the moment (although there will be in #280).
From my perspective, sshkit should properly escape shell commands by default due to high security implications. It would be too much of a burden to have users of sshkit make sure of correct escaping (although it is rather easy with
Shellwords::escape
).May I suggest to reintroduce proper shell escaping. Users with the need to run unescaped command (which I do not dispute) should be using a new and different method, e.g.
execute_unescaped
, instead ofexecute
.Feedback is very welcome!
The text was updated successfully, but these errors were encountered: