[BUG] JSON.stringify should not be used for shell escaping

[jbms]

run-script uses JSON.stringify to quote/escape command arguments:

run-script/lib/run-script-pkg.js

Line 30 in 477a99c

cmd = pkg.scripts[event] + args.map(a => ` ${JSON.stringify(a)}`).join('')

However, shells don't use the same quoting rule as JSON, which leads to incorrect behavior. In particular, literal newline characters (NL) get converted to \n (BACKSLASH N) by JSON.stringify, but bash does not treat \n as an escape sequence, and as a result the script receives \n (BACKSLASH N) as its argument.

To fix this problem, shell escaping should be used instead of JSON stringify.

I ran into this calling a script that invokes webpack with a --define argument containing a literal newline (NL) character. npm 7 converts this to a \n, which results in webpack substituting invalid javascript code leading to a parse error.

[Alhadis]

This is a serious security risk. Consider something like

npx write-script > output.js \
	--footer '// Run `rm -rf $PATH_TO_YOUR_PROJECT/**` to clean'

where the script author has enclosed rm -rf … in single-quotes to avoid executing it. Since $PATH_TO_YOUR_PROJECT is unlikely to be defined in one's environment, NPM ends up running something like

sh -c write-script "--footer" "// Run `rm -rf /**` to clean"

... at which point, it's game over.

The problem extends to usage of $ as well, which isn't escaped because it isn't a metacharacter in JSON, but it sure as hell is in shell-scripts ($(cmd), ${variable_name}`, etc).