On 26/09/14 07:06, Mailing Lists (???) wrote: > Even if we agree to shift /bin/sh to dash, I'm not sure that it'll make > that much of a difference. From what I've read, most of the problems > come from CGI scripts which invoke bash, and ssh post-authentication. Anything that uses system(), popen(), or other similar "invoke command (implicitly via /bin/sh)" functions can be affected by problems with whatever is installed as /bin/sh. Some daemon configurations have lines for hooks: "invoke shell command when <event> occurs", with information passed to the command by various means (parameters, environment variables, etc.). Some programs allow specification of I/O targets as pipes to or from shell commands. There is a _lot_ of "magic behavior" in bash. Debian bug #762839 mentions how bash still imports shell functions from environment variables with magic names, even when called as sh. The --posix option seems something of a joke. dash has some of this as well (in particular, it interprets CDPATH) but not nearly as much, and it's much less likely to gain more in the future. I would support a move to dash as sh, but it's not primarily for security per se but for general cleanliness: bash as sh does more to encourage the proliferation of "presumptive bashisms" and has much more potential for future breakage in central system areas. I believe this is more in line with Arch's "Simplicity" and "Code-correctness over convenience" principles than conflating the needs of interactive and whole-system-default shells for convenience's sake, especially if bash is a moving target regarding which features might be enabled that might interfere with global functionality. I would not support a move of the _packaging_ system to another sh, because that's explicitly documented to use bash as its main scripting language and relies on its extended features, and the potential complications are better contained. I don't think that's relevant unless the current packaging system assumes that bash can be invoked as sh. The case of interactive SSH is separate, because that depends on the user's interactive shell, not sh. The case of machine SSH in which the target account's shell is sh falls loosely into the program-program interoperation category. On my own desktop system, when I realized sh was bash recently I immediately relinked it to dash and intend to keep it that way as long as I reasonably can (I assume some things may break, in the current state; I'm willing to deal with that on my own for now). ---> Drake Wilson
