Unfortunately, bash shows up in surprising places, including default Solaris installs nowadays.

On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect so far. I'll put more effort into establishing its acceptability as a solution tomorrow.

BSDs won't have bash unless someone has gone out of their way to install it, which can be undone straightforwardly.

But it could be a long night for our Linux brethren and sistren.

Good luck, and remember to stay hydrated. :)

EDIT: obviously, don't chmod 0000 your login shell! Fix that first. Make sure whatever you switch to isn't a symbolic or hard link to bash.

In the case of OSX, /bin/sh is also bash. For some reason they are separate binaries (at least on my laptop running 10.9.5) but they're both really bash inside:

    $ ls -ld /bin/sh /bin/bash
    -r-xr-xr-x  1 root  wheel  1228240 Sep 21 21:37 /bin/bash
    -r-xr-xr-x  1 root  wheel  1228304 Sep 21 21:37 /bin/sh
    $ /bin/sh --version
    GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
    Copyright (C) 2007 Free Software Foundation, Inc.
    $ /bin/bash --version
    GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
    Copyright (C) 2007 Free Software Foundation, Inc.

(ETA: as I've mentioned elsewhere in this thread most people running OSX probably aren't badly impacted since they're not running CGI-based web software or other high-risk activity. I'm just pointing out that your bash-ectomy of OSX isn't as complete as you think it was)

There might be more of an impact than expected on OSX, too -- no telling what Apple does with their system services.

We've seen mention of dhcp-client and CUPS. The latter, at least, could also be an issue on OSX.

So while a lot of people are affected, your reasoning points to other issues that are very solveable

I specifically said any decent shell script. My logic is that if it is not using "sh", but instead relying on bash (or any other specific shell really), it's not a decent shell script.

If I were to amend the sentence to make the meaning clearer, I would still not use "should be", I would use "must be".

It's a considered decision, not a sign of "indecency".

"Decent shell script" is not a synonym for "portable shell script" and the presumption therein is what I was addressing.

Writing to '/bin/sh' is understandable due to its ubiquitousness.

Bash is a superset that is not so ubiquitous, so it doesn't have the advantage that writing to /bin/sh does.

If you don't want portable, then don't write to shell script. Write to Perl Ruby or Python, which is also safer and more secure.

However, unless you are patching and compiling the same version of Bash, you absolutely do not have the same version on all those machines, and that is the whole reason NOT to target Bash in shell scripts - its features are not always consistent/compatible across versions.

Yes. Yes. Yes. Yes. No (unless Cygwin is installed).

(I have init scripts for Cygwin, too, because I need Windows but life is too short for CSRSS.)

You intended that subjunctive clause to apply to all the sentences, an intent I missed. My mistake. :)

This may soon become a tempest in a teapot, as patched Bash versions are now appearing. I just patched all my machines.

Only for you. For me and a lot of others I suspect, if it isn't portable it isn't worth the trouble.

If you have to re-compile a newer/older version of a shell to get the same results across machines, any potential benefits start to seem insignificant compared to the effort involved.

How do you handle situations where bash is included by default?

Do you remove the package or just push your binary over the top?

If you don't remove it, what happens when a package update then replaces your binary?

How often do you update the recipe to make sure it's getting the latest stable version and applying security patches?

No, I have a chef recipe to install the newest version of bash 4 everywhere. How is an implementation detail. (I use Ubuntu packages and Homebrew, I only compile on cygwin.)

> How do you handle situations where bash is included by default? Do you remove the package or just push your binary over the top?

On OS X, the only place that's the case, I replace the binary (by using the Homebrew-compiled one).

> How often do you update the recipe to make sure it's getting the latest stable version and applying security patches?

I've written the Chef recipe to not need regular updates. I run my Chef update stuff on a weekly basis. I can do so manually if I need to.

This is my whole point - targeting /bin/sh means targeting a POSIX compliant shell, which may be implemented by any number of different codebases, with a defined standard to meet. Posix mode in Bash 4.3 should be the same as Posix mode in Bash 3.9, etc. - targeting /bin/bash means targeting whatever specific bash oddities come with the version installed.

Don't get me wrong: I could use /bin/sh. But I would have to write worse code to do it. I'll take the possibility of a bash regression over writing all my shell scripts in sh.

In my experience most of the shell scripts provided by packages for debian, do use /bin/sh.

A quick check of .sh files on a couple of squeeze/wheezy installs showed that the vast majority of shell scripts using Bash come from node modules, which quite frankly is not surprising.

By default Debian still uses Bash for interactive user shells, but since Squeeze (early 2011), /bin/sh is provided by Dash.

Dash is used because it's faster than Bash and has less dependencies so its more resilient to failures.

for more info see https://wiki.debian.org/Shell, https://wiki.debian.org/DashAsBinSh and https://packages.debian.org/wheezy/dash

But, to clarify for others, the existing shellshock PoC doesn't work on the busybox environment I tested (v1.20.2).