Re: Bash security issue

[Linda Walsh]

Eric Blake wrote:
> Where I'm coming from is that in portable shell programming, you _can't_
> assign a value to f()=...  The fact that portable
> programs are now "slammed"[sic] with the notion that some values cannot be
> portably assigned to a variable...
---
slammed?  It's not like this is new...

> > Not much more secure, but ..'ƒ(8-byte-crypto-hex-sig)'
> Overkill.  
---
        Ya think?

        I mean isn't the world held together by duct-tape, bailing-
wire and bash (or -compat) scripts?  Anyway, it was also meant
as a "if you really are serious about solving this and don't care
about the overhead or inconvenience..." illustration of panic-driven
design.

Eric Blake wrote:
> It's not backwards compatible, but who cares? only matters
> if you are mixing old and new bash...
>  But the old bash behavior is so bad that  people are unlikely to 
> want to have both shells installed.
---
Oh come on... "so bad"?

As other have said:

   «Geir Hauge wrote: Bash has had this feature since "forever"»

   «Pierre Gaston wrote:  How many instance have you found since the
    introduction of this feature more than 20 years ago?»



This behavior has been around for 20+ without it being judged "so bad",
so lets not be tempted toward knee-jerk reactions.  That it is now known
about makes some protections more urgent, but panicking over security fixes
often results in stupid knee-jerk "fixes"[sic] that only need to be
re-fixed [fixed] later on.

That it is a bug that should be fixed, no argument.
Your idea of using "f()=" in the ENV is sounds reasonable (though
not nearly so elegant as using the unicode 'function' symbol, 'ƒ' instead of
empty parens, in memory (ENV) -- not as to what a user would type.
The '()' is already overloaded w/meaning, "null set", or "empty array
assignment", depending on context.