Sean Russell wrote:
> In fact, as far as I can tell, Strings are the only things where taintedness
> is "inherited" to other objects derived from tainted objects.
[...]
>  If so, why do most objects not do
> so?  If not, why do Strings do so?

My understanding is that taintedness is highly connected to the security
issues of executable text, be it from CGI forms, GUI user input or
otherwise.

How a user would insert a "malicious" array is beyond me, but you could
potentially pack it into a binary string, write it to a file and execute
it as machine code. However, this would require several usage steps of
the programmer. With strings it is far to easy to chuck it along into
some dynamic function and opening a major security hole without much
many statements to awake your consciousness.

So I feel safe enough with only Strings inheriting taintedness, since
Strings are so close to the inner workings and black magic of Ruby
itself, while most other objects use taintedness with a more
application-level usages.

Though I have to say this little bit felt rather counter-intuitive:
irb(main):001:0> a = [1]; b = [2]; a.taint; b.taint
[2]
irb(main):002:0> (a+b).tainted?
false
irb(main):003:0> VERSION
"1.6.7"

Perhaps Matz is running with the YAGNI principle here, waiting for us to
think up some sensible usage of inherited tainting in Arrays and other
non-String objects?

-- 
(\[ Kent Dahl ]/)_    _~_    __[ http://www.stud.ntnu.no/~kentda/ ]___/~
 ))\_student_/((  \__d L b__/  NTNU - graduate engineering - 4. year  )
( \__\_?|?_/__/ ) _)Industrial economics and technological management(
 \____/_?_\____/ (____engineering.discipline_=_Computer::Technology___)