Re: Fwd: Non-upstream patches for bash

[Bernhard Hermann <bernhard.hermann () gmail com>]

On 29 Sep 2014 08:40, "Sven Kieske" <s.kieske () mittwald de> wrote:
> On 27/09/14 17:06, Solar Designer wrote:
> > Of course, what input is trusted vs. not may be unclear.  Apparently, 20
> > years ago bash developers considered all env vars to be trusted input,
> > regardless of the names, which is how we got here.

> 'Input sanitization: “you can suppress ‘bad
> stuff’ in input+output to make it safe”
>
> Reality: Halting problem. Deal with it.'

This seems to me to be the good old CODE vs. DATA issue.

IMHO, ENV vars are supposed to always be DATA, never CODE.
If code is allowed, the parser might always fail. Judging by the recently
dug up dirt, it most certainly will.
Passing code as ENV is an ugly hack, probably born out of necessity arising
when trying to implicitly propagate code, because no alernatives are
apparent, are they?

If it's done at all, it should at least be explicit.

That's why I'm voting for having the *BSD approach in upstream: make the
parsing of ENV vars optional, default OFF.

br,
Bernhard Hermann