Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Add support for execFile-like interface to exec #495
Comments
This adds an initial implementation of shell.cmd(), which is intended as the eventual replacement for shell.exec(). This PR does not fully implement the API, but demonstrates a simple and secure alternative, and will allow further iteration to cover other use cases in follow-up PRs. Design doc: https://shelljs.page.link/cmd-design Issue #495 Test: automated test suite
|
Any news for this one? |
|
I'm still hoping to work on this. Unfortunately, it's really hard to provide reasonable behavior on Windows (#866 basically works for unix). I vaguely remember issues with v4/v5--now that we've dropped those, I need to check if this project is feasible. |
|
Any news for this one? |
|
No major update. This is quite difficult to get right for Windows, and I don't have a machine anymore to speed up investigation. This is something I'm very interested in solving when I have more time & resources. |
Add a new command to launch external shell commands, providing a less vulnerable alternative to exec(), with cross-platform globbing. Fixes #143
|
Updated the description, but this is not a security vulnerability/fix, rather this is an implementation of a feature request. Please follow #945 if you'd like to read discussion regarding how Snyk's report is misattributed. If you're interested in being a consumer of this particular API, you're welcome to continue asking questions here (but you'll probably hear an update from me as soon as there's something to update). |
This adds an initial implementation of shell.cmd(), which is intended as the eventual replacement for shell.exec(). This PR does not fully implement the API, but demonstrates a simple and secure alternative, and will allow further iteration to cover other use cases in follow-up PRs. Design doc: https://shelljs.page.link/cmd-design Issue #495 Test: automated test suite
This adds an initial implementation of shell.cmd(), which is intended as the eventual replacement for shell.exec(). This PR does not fully implement the API, but demonstrates a simple and secure alternative, and will allow further iteration to cover other use cases in follow-up PRs. Design doc: https://shelljs.page.link/cmd-design Issue #495 Test: automated test suite
This adds an initial implementation of shell.cmd(), which is intended as the eventual replacement for shell.exec(). This PR does not fully implement the API, but demonstrates a simple and secure alternative, and will allow further iteration to cover other use cases in follow-up PRs. Design doc: https://shelljs.page.link/cmd-design Issue #495 Test: automated test suite
This adds an initial implementation of shell.cmd(), which is intended as the eventual replacement for shell.exec(). This PR does not fully implement the API, but demonstrates a simple and secure alternative, and will allow further iteration to cover other use cases in follow-up PRs. Design doc: https://shelljs.page.link/cmd-design Issue #495 Test: automated test suite
|
I just had to look into this, and I found child_process.spawn. It seems to me that this should be used (with If it turns out that windows can't execute scripts directly, it should be just a matter of passing the shell executable as the cmd and the script as the first argument. |
|
I worked around those issues in #866 by using https://github.com/sindresorhus/execa, which seems to handle Windows much more nicely than anything I had figured out by hand. That PR implemented "step 1" outlined in https://shelljs.page.link/cmd-design, but I think we'll need to implement step 2 before we can deprecate |
It would be great if
exechad an interface, perhaps like the following:This is great because of the following:
fileName = 'file1.txt file2.txt'means the git call will search for one file namedfile1.txt file2.txt, not two separate files)child_process.execFileexec()won't glob-expand)shx(shelljs/shx#65 & shelljs/shx#68)exec('echo', env.PATH)vs.exec('ls $PATH')), which is the safer approachexecwill respect a call toset('-f')The issue with this interface is what to do when we have only 1 argument (do we use the old behavior or the new
execFileimplementation?). An alternative approach isexec([arg1, arg2, arg3]), which uses a list to remove ambiguity. This is easier to parse, but perhaps not as nice to work with.Edit: to clarify, this is a feature request, not a security vulnerability. This new API would be easier to use safely than
shell.exec(), butshell.exec()is not itself vulnerable and can in fact be used safely without much difficulty (see security guidelines).