<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Hello,<br></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr">On Thu, Oct 2, 2014 at 10:48 AM, Tom Rivers wrote:<br><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid #cccccc; padding-left: 1ex;"><span class=""><span class="">On 10/2/2014 09:58, Rahul Sundaram wrote:<br></span></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid #cccccc; padding-left: 1ex;">I didn't address it because it was not really relevant either. The impetus is merely the backstory.<br></blockquote> On the contrary, the rationale for your proposed change is very relevant. <br></blockquote><br></div><div class="gmail_quote">Sure but the rationale isn't just security as I have explained earlier. Do read the links and other mails fully.</div></div></div></div></blockquote><div>OK, then; care to explicitly list the advantages you expect to see from such a switch, and why they outweigh the disadvantages and the migration costs?<br></div><div><br></div><div>AFAICS:<br></div><div><br></div><div>The expected security improvement is essentially nonexistent. In the current case of importing functions from the environment (and we could have a looong philosophical conversation about whether this is a vulnerability in bash or in its callers, where the likely outcome is “not a vulnerability in bash but by far easiest to fix in bash”), I expect/hope that the environment variable channel has been audited to death. Outside of this case, the shell is, by its nature, a programming language interpreter, and it doesn’t do any kind of privilege escalation: if you feed it arbitrary input, you get to do arbitrary things, but no more than you could do without the shell. The shell really should be transparent/fairly irrelevant to security (which is also why so little attention has been paid to it).¹<br></div><div><br></div><div>And as for any measure of performance, by the very fact that the scripts are written in shell we already know that the scripts are not performance-critical, or at least have not been worth optimizing for performance.<br></div><div><br></div><div>So, it seems to me, all we are left with is a bit of performance/space optimization just because we can, at the very real cost of breaking existing scripts, both within the distribution and on users’s systems.<br></div><div> Mirek<br></div><div><br></div><div>¹ The exceptions being attacks through other programs that do escalate privileges and call shell with untrusted data (as in shellshock), and attacks through the shared environment (in this case, mainly filesystem contents and various small/constrainted states like the PID space).<br></div></div></body></html>