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

[Hugo Osvaldo Barrera]

On 2014-09-26 07:30, Drake Wilson wrote:
> 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 strongly agree with this. Programs that ask for sh should get sh, and
programs that ask for bash should get bash.

Programs that ask for bash and use bashisms are already broken for the Ubuntu
family (ie: Ubuntu and derivates), and on any *BSD, and *need to be fixed
upstream*!

I also remember having to port some scripts from BSD to Arch and seeing how
they broke on bash because bash has non-sh behaviours.

Bash is not sh, and should not be treated as such. I've no issue with having
bash in my system and that scripts with the proper shebang use it.

> 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

-- 
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20140926/6179303c/attachment.bin>