On 09/26/2014 02:57 PM, Doug Newgard wrote:
You're wanting it to hide functionality in certain circumstances, which isn't wrong, but it isn't required. One way is not more correct than the other.
I think not doing stupid things with env vars qualifies as "more correct."
Smaller code bases can have the potential to be more secure, but that doesn't mean that they are. The shear amount of testing Bash gets run through being the default shell for so many things would suggest that it's likely more secure than a code base that doesn't get this testing.
As a result of "shellshock," we've discovered there are unpleasant surprises lurking in the bash code base in spite of its proliferation. Either this speaks volumes about the possible problems with other tools (maybe) or it's illustrative that "extensive testing" in real world usage doesn't cover *every* possible code path (likely). Interpretation of the "(){}" syntax in environment vars, I believe, is used by bash as a means of passing functions into subshells and was never intended to be exposed to end user code. Without careful auditing, I doubt this would have been discovered via ordinary real world use.
I also think this is a red herring.
Let's look at security through obscurity. When Apple started making their comeback, one of the big reasons non-technical people gave over and over for switching is that OSX didn't have any viruses. As it became more popular, guess what happened? Simply put, the smaller the install base, the less motivation there is to break it. Dash has a far smaller install/user base than Bash, so Bash is a much larger target.
Again, I disagree. Replacing a sh-like shell with another sh-like shell is certainly *not* security through obscurity. dash is the default shell on Debian and, AFAIK, recent Ubuntu installs (I see it on 13.10 and 14.04, probably much earlier, too). And as far as Linux goes, Ubuntu can arguably claim the title of one of the most widely installed distributions. So not only does this imply dash is fairly widely installed (not as much so as bash, but still fairly common), but targeting it instead of bash might make available machines that otherwise don't expose bash via certain interfaces (e.g. popen(), Apache, etc). Hence I think this argument *sort* of works, but it's a stretch.
dash and bash both hail from 1989, so the age is also close. Perhaps comparing the estimated number of installs versus total LOC might be an interesting metric.
Curiously, vulnerable versions of bash exist on OSX and in some Windows applications (Cygwin, Github's Windows app via msysgit). How's that for cross-platform support?
My technical reason is simple, I don't think the base install should have to include another shell implementation when one is already available. If you want to switch /bin/sh on your machine, go for it. I just don't think having it as the default is a good way to go.
Fair enough. There are means to do exactly that, and the beauty of Arch is that user-level customization is easy.
I'd like to add that dash weighs in at 104KiB versus bash's 774KiB. Installing both comes in under 1 MiB. So I'm still trying to understand the hostility against having both packages installed.
Benjamin
