[arch-general] A good time to switch to dash as /bin/sh?

[Drake Wilson]

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