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
