On Fri, Sep 26, 2014 at 6:08 AM, Linda Walsh <bash@xxxxxxxxx> 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.
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
