<div dir="ltr">Just my 2c - it's not hard to download (outside of macports) and compile bash + latest patches. You can also match the bash rev (3.2 on my SL machine) to have minimal impact from any changes to bash behavior.<div><br></div><div>As noted in the thread, changing the core OS executables is something you do AT YOUR OWN RISK.<br><div><br></div><div><div>$ /bin/bash --version</div><div>GNU bash, version 3.2.52(2)-release (i386-apple-darwin10.8.0)</div><div>Copyright (C) 2007 Free Software Foundation, Inc.</div><div>$ /bin/orig/bash --version</div><div>GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)</div><div>Copyright (C) 2007 Free Software Foundation, Inc.</div></div><div><br></div><div>This also links against the system libs, so you won't have a borked system if you ever decide to uninstall macports.</div></div><div><br></div><div> - Eric</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 29, 2014 at 8:35 AM, Lee Bast <span dir="ltr"><<a href="mailto:x-lists@asgarda.com" target="_blank">x-lists@asgarda.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> New exploit variants (CVE-2014-6278), this looks like the vuln that'll keep on giving until bash has a more fundamental fix decided upon. In the mean time, would it be worth giving any consideration to the NetBSD patch that simply disables default environmental function importing? Both NetBSD and FreeBSD have adopted that as an interim solution:<br>
• <a href="http://seclists.org/oss-sec/2014/q3/755" target="_blank">http://seclists.org/oss-sec/2014/q3/755</a><br>
• <a href="http://seclists.org/oss-sec/2014/q3/802" target="_blank">http://seclists.org/oss-sec/2014/q3/802</a><br>
• <a href="https://svnweb.freebsd.org/ports/head/shells/bash/files/extrapatch-import-functions?revision=369467&view=co&pathrev=369467" target="_blank">https://svnweb.freebsd.org/ports/head/shells/bash/files/extrapatch-import-functions?revision=369467&view=co&pathrev=369467</a><br>
A variant with that patch seems like a promising approach to avoid the whack-a-mole game. In that thread they discuss simply abandoning backwards compatibility entirely and removing it, but arguments either way and that seems like a step too far for MacPorts as well. But making it an explicit flag/warning might be a good compromise.<br>
<span class=""><br>
On Sep 29, 2014, at 0453 , René J.V. Bertin <<a href="mailto:rjvbertin@gmail.com">rjvbertin@gmail.com</a>> wrote:<br>
> - how about adding a variant to the bash (and dash) portfiles allowing users to copy the MacPorts version into /bin (moving the original version to something like bash.macportsBackup if that backup doesn't yet exist)?<br>
<br>
</span>Beyond what Rainer Müller said, what do you mean "allowing"? There's nothing stopping you from just copying it over or linking it yourself while renaming/-x'ing the standard ones. You'll have to test your own setup of course, but it should be trivial to revert, and FWIW I saw no issues after giving it a shot in a few VMs and a test system.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
macports-users mailing list<br>
<a href="mailto:macports-users@lists.macosforge.org">macports-users@lists.macosforge.org</a><br>
<a href="https://lists.macosforge.org/mailman/listinfo/macports-users" target="_blank">https://lists.macosforge.org/mailman/listinfo/macports-users</a><br>
</div></div></blockquote></div><br></div>