Re: declare a="$b" if $a previously set as array

[Stephane Chazelas]

2014-12-15 05:41:51 -0600, Dan Douglas:
> So I'm still getting caught up on this thread, but hasn't this issue been done
> to death in previous threads? Back when I was examining bash's strange declare
> -a, you were the very first person I found to notice its quasi-keyword 
> behavior
> 10 years ago
> (https://lists.gnu.org/archive/html/bug-bash/2004-09/msg00110.html). Perhaps
> you didn't realize what this was doing at the time?
[...]

I can't say I remember that one, but note that was a different
case that was later fixed. That was about:

    declare -a a=("$b")

where the content of $b was further evaluated.

$ b='$(uname>&2)' bash-2.05b -c 'declare -a a=("$b")'
Linux

That one was more clearly a bug as no one could really be
expected to escape the content of $b there.

I probably did not notice at the time that it was also the case
with:

declare -a a="(...)"

though it would never have occurred to me to use that syntax
(although it's true that's the syntax that is used by declare -p)

As previously mentionned, another related bug that was also
reported over 10 years ago:

http://lists.gnu.org/archive/html/bug-bash/2003-10/msg00065.html

That one was about:

a=($var) or a=(*) (without or without "declare") where the
resulting words may be of the form: [0]=foo (and then, I had
not realised at the time that it was a code injection
vulnerability as well):

$ a='[0$(uname>&2)]=foo' bash-2.05b -c 'b=("$a")'
Linux

-- 
Stephane