ENV variables and tainted input

Is it advisable to always use ENV[‘SOME_VALUE’].dup ?

I seem to stumble into … tainted input problems or something
like that, and this seems to happen only with ENV stuff.

It is as if the attitude is to never trust these values,
but I can handle incorrect ENV values from within my ruby
script anyway, so I am wondering a bit about the logic
behind this.

Has the use of .dup any serious disadvantage?

On Jul 5, 2012, at 13:46, Marc H. wrote:

Is it advisable to always use ENV[‘SOME_VALUE’].dup ?

There is no point:

$ ruby -e ‘p ENV[“PATH”].equal? ENV[“PATH”]’
false

You’ll always receive a new object from ENV, so the dup wastes an
object.

I seem to stumble into … tainted input problems or something
like that, and this seems to happen only with ENV stuff.

Objects from ENV are always tainted. If you run at $SAFE > 0 you need
to untaint them for some operations (usually after performing a check on
the value for safety).

It is as if the attitude is to never trust these values,
but I can handle incorrect ENV values from within my ruby
script anyway, so I am wondering a bit about the logic
behind this.

Has the use of .dup any serious disadvantage?

I wouldn’t call wasting an object a serious disadvantage. The GC will
clean it up.

Also note that dup copies the tainted state of an object:

$ ruby -e ‘s = “”; p s.tainted?; s.taint; p s.tainted?, s.dup.tainted?’
false
true
true