On Fri, Oct 10, 2014 at 6:13 AM, Barrie Stott <zen146...@zen.co.uk> wrote:
> Wouldn't the stopping of function export from MacPorts' bash be a big > restriction on bash use. For example, I want to be able to type "mvim", > with or without parameters, to open a MacVim window. At present, I get the > error: > "/bin/sh: line 8: `BASH_FUNC_usenosql%%': not a valid identifier". Would > not the prevention of function export prevent me from opening a MacVim > window? > Nope. This is still the Shellshock attack vector, just with a little protection around it: bash is opportunistically sucking in functions from the environment and blindly eval-ing them, to no purpose in this case. If anything, defining the wrong functions could break MacVim in very obscure ways, instead of this obvious one. User functions should not be visible to system level shell scripts; they should be deterministic, not randomly modifiable by the user's environment. The correct thing to do is, and always has been, to define functions in your dotfiles and not have them affect arbitrary shells, only interactive-mode ones. MacVim in particular knows how --- and when --- to run the shell in this mode and get your functions. This is why the Debian/FreeBSD patch is the correct one, but Bash upstream and Red Hat refuse to do the right thing in this case... and this means, among other things, that Shellshock-patched bash is not compatible with unpatched bash if you define shell fucntions, which is the source of your immediate problem. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
