Re: Bash security issue

[lolilolicon]

On Fri, Sep 26, 2014 at 6:08 AM, Linda Walsh <bash@tlinx.org> wrote:
>
>
> 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...

I think it's new to the majority of people.

>
>>> 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.

I sensed that ("ƒ(8-byte-crypto-hex-sig)") was sarcasm. Not cool :(

"panic-driven design" would be bad,
but a wise man once uttered,

   "Just because you're paranoid, don't mean they're not after you."

>
> 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",

I don't think that's a sufficient argument for "this is not so bad".

First, the fact that the bug has existed for so long, yet fails to be
discovered [disclosed] until now, is proof that this feature is very
little used and rarely tested, not an argument for "it's not so bad".

Second, this has been a dark corner of bash, a blind spot for most
people, including security people and crackers. Now it's in the
spotlight. And now we are seeing a can of worms crawling out of the
dark.

> 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.

Just as bad is the decision to introduce a poorly thought out "it would
be nice" feature, get busted 20 years later, and have to fix it trying
to maintain backward-compatibility.

The wisdom from above has taught,

    "Unwritten code is debugged code."
    "The most productive days was removing 1000 lines of code."

Unfortunately, when a project grows so popular, it gets trapped in its
own past.

> 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.

And of course there is no such meaning. It's all in your head.