On 29/09/14 12:27, Nathan Ward wrote:
Seems a reasonable suggestion to stick with what’s getting the most attention from the security angle. Then again, maybe dash will get that now too - is it less code/simpler to audit?
bash_4.3.orig.tar.gz: 7.2MB dash_0.5.7.orig.tar.gz: 219K Looks significantly smaller to me :-) FWIW, people who have been looking at the bash code haven't come away all that impressed: http://blog.erratasec.com/2014/09/the-shockingly-bad-code-of-bash.html (yes, the URL gives away the punchline.) ash (http://en.wikipedia.org/wiki/Almquist_shell) and variants of it (dash is Debian's variant of ash) have been used on several of the BSDs for years too. So the base ash code is pretty widely used. I'd certainly be wary of just using some random hardly-used thing no one else was using. But of the alternative free /bin/sh implementations, (d)ash appears to be the most widely used, over the most extended period.
To quote an esteemed security chap, who said privately, not necessarily in endorsement of my thoughts above: "you want many eyes argument? there are MANY eyes looking now ;)"
And so far we're averaging a security bug a day.... I certainly agree the many eyes argument is finally at work for bash. But it's unclear to me whether it's actually practically possible to get to a "secure in the face of untrusted input" state. I also agree that it's entirely possible that bugs will be found in (d)ash too, and would expect people to start looking. But the bash bugs are what are being attacked directly (eg, botnets), in the wild, right now. So it's worth thinking about your choice of /bin/sh. Ewen