# "Taint" and (internal) copy constructors **URL:** \ **Category:** IronRuby\ **Created:** [October 25, 2007, 8:06am UTC](https://www.ruby-forum.com/t/taint-and-internal-copy-constructors/118262 "2007-10-25T08:06:31Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![curthibbs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ac91a4/32.png) [@curthibbs](https://www.ruby-forum.com/u/curthibbs)\ **Post date:** [October 25, 2007, 8:06am UTC](https://www.ruby-forum.com/t/taint-and-internal-copy-constructors/118262/1 "2007-10-25T08:06:31Z")
Currently, the copy constructors for the MutableString class will “lose” the taint flag on the string being copied. One practical consequence of this is that any builtins that store local copies of the MutableString would have to manually fix the taint flag. Wouldn’t it be better if the default behavior were to preserve this information? Under CRuby, a = “123” =\> “123” a.taint =\> “123” a.clone.tainted? =\> true a[1,1].tainted? =\> true Under IronRuby, a = “123” =\> “123” a.taint =\> “123” a.clone.tainted? =\> true a[1,1].tainted? =\> _false_ It appears that RubyUtils.TryCopyObject is the only place where this flag is preserved, and this function is called by both Object.clone and Object.dup. ---
**Author:** ![curthibbs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ac91a4/32.png) [@curthibbs](https://www.ruby-forum.com/u/curthibbs)\ **Post date:** [October 25, 2007, 8:15am UTC](https://www.ruby-forum.com/t/taint-and-internal-copy-constructors/118262/2 "2007-10-25T08:15:16Z")
Freezing and tainting are not supported yet. We have only “stubs” for them today. Tomas From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Curt Hagenlocher Sent: Wednesday, October 24, 2007 11:06 PM To: removed\_email\_address@domain.invalid Subject: [Ironruby-core] “Taint” and (internal) copy constructors Currently, the copy constructors for the MutableString class will “lose” the taint flag on the string being copied. One practical consequence of this is that any builtins that store local copies of the MutableString would have to manually fix the taint flag. Wouldn’t it be better if the default behavior were to preserve this information? Under CRuby, a = “123” =\> “123” a.taint =\> “123” a.clone.tainted? =\> true a[1,1].tainted? =\> true Under IronRuby, a = “123” =\> “123” a.taint =\> “123” a.clone.tainted? =\> true a[1,1].tainted? =\> false It appears that RubyUtils.TryCopyObject is the only place where this flag is preserved, and this function is called by both Object.clone and Object.dup. ---
**Author:** ![curthibbs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ac91a4/32.png) [@curthibbs](https://www.ruby-forum.com/u/curthibbs)\ **Post date:** [October 25, 2007, 11:37am UTC](https://www.ruby-forum.com/t/taint-and-internal-copy-constructors/118262/3 "2007-10-25T11:37:10Z")
Curt H. wrote: > Currently, the copy constructors for the MutableString class will “lose” > the taint flag on the string being copied. One practical consequence of > this is that any builtins that store local copies of the MutableString > would have to manually fix the taint flag. Wouldn’t it be better if the > default behavior were to preserve this information? JRuby mimics this behavior, but we’ve debated just kicking taint and SAFE out the window. They’re not provably safe (even in MRI), so they’re almost certainly unsafe…and woah, the overhead. Most folks using JRuby now just assume neither work. - Charlie ---
**Author:** ![curthibbs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ac91a4/32.png) [@curthibbs](https://www.ruby-forum.com/u/curthibbs)\ **Post date:** [October 25, 2007, 5:26pm UTC](https://www.ruby-forum.com/t/taint-and-internal-copy-constructors/118262/4 "2007-10-25T17:26:01Z")
On 10/25/07, Charles Oliver N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > JRuby mimics this behavior, but we’ve debated just kicking taint and > SAFE out the window. They’re not provably safe (even in MRI), so they’re > almost certainly unsafe…and woah, the overhead. > > Most folks using JRuby now just assume neither work. Both taint and frozen have a very 90s Perl feel to them :). Being new to Ruby, I have absolutely no feel for how often they’re used (with CRuby). ---
**Author:** ![curthibbs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ac91a4/32.png) [@curthibbs](https://www.ruby-forum.com/u/curthibbs)\ **Post date:** [October 25, 2007, 6:25pm UTC](https://www.ruby-forum.com/t/taint-and-internal-copy-constructors/118262/5 "2007-10-25T18:25:42Z")
On 10/25/07, Charles Oliver N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > frozen is another thing entirely, and it has good uses (locking down > strings and arrays so they can’t be modified, for example). Are extensions not able to ignore “frozen”, then? Other than strings and arrays, it’s hard for me to see a compelling reason for this feature. But then, my thinking is undoubtedly influenced by Python, where strings are immutable and “frozen arrays” are called tuples. 🙂 More to the point of this list, though, how can you decide which features of CRuby to ignore? It can’t just be a matter of overhead, because the overhead for “taint” seems to be almost exactly the same as that for “frozen” – both features require you to keep external bookkeeping information for objects defined outside of Ruby when the feature is used. ---
**Author:** ![curthibbs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ac91a4/32.png) [@curthibbs](https://www.ruby-forum.com/u/curthibbs)\ **Post date:** [October 25, 2007, 5:54pm UTC](https://www.ruby-forum.com/t/taint-and-internal-copy-constructors/118262/6 "2007-10-25T17:54:40Z")
Curt H. wrote: > Both taint and frozen have a very 90s Perl feel to them :). Being new > to Ruby, I have absolutely no feel for how often they’re used (with CRuby). frozen is another thing entirely, and it has good uses (locking down strings and arrays so they can’t be modified, for example). But taint/SAFE are (IMHO) ugly, dated mechanisms for handling security, by sprinkling security checks all over high-level method calls and hoping you don’t miss any. Not to mention extensions can ignore tainting completely. Yucko. - Charlie ---
**Author:** ![curthibbs](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/ac91a4/32.png) [@curthibbs](https://www.ruby-forum.com/u/curthibbs)\ **Post date:** [October 25, 2007, 7:24pm UTC](https://www.ruby-forum.com/t/taint-and-internal-copy-constructors/118262/7 "2007-10-25T19:24:13Z")
Curt H. wrote: > On 10/25/07, _Charles Oliver N._ \ [mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\> wrote: > > ``` > frozen is another thing entirely, and it has good uses (locking down > strings and arrays so they can't be modified, for example). > > ``` > > Are extensions not able to ignore “frozen”, then? No, extensions can pretty much do anything they want, which is why they suck and why it’s nearly impossible for any non-C-based implementation to ever support them. > Other than strings and arrays, it’s hard for me to see a compelling > reason for this feature. But then, my thinking is undoubtedly > influenced by Python, where strings are immutable and “frozen arrays” > are called tuples. 🙂 Even .NET and Java collection libraries provide ways to get immutable collections; it’s similar to this. But regardless of whether you think it’s useful, the important point is below… > More to the point of this list, though, how can you decide which > features of CRuby to ignore? It can’t just be a matter of overhead, > because the overhead for “taint” seems to be almost exactly the same as > that for “frozen” – both features require you to keep external > bookkeeping information for objects defined outside of Ruby when the > feature is used. You can decide what features to ignore once you know what features are needed for existing apps to run. For example…JRuby can run Rails and just about anything else that’s pure Ruby, so we’ve been able to determine that certain optimizations are safe and certain features can be safely “unsupported”. It’s really, really hard to make that determination before you can run nontrivial apps, but you can learn from others. I’d say the only feature we gave up on early was continuations, and I actually made a serious effort to support them until we discovered how infrequently they were used in the real world. I shall miss my stackless interpreter, slow though it was. - Charlie