# Code Review: 19compat **URL:** \ **Category:** IronRuby\ **Created:** [July 19, 2010, 10:46pm UTC](https://www.ruby-forum.com/t/code-review-19compat/191863 "2010-07-19T22:46:57Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![grujildo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/94ad74/32.png) [@grujildo](https://www.ruby-forum.com/u/grujildo)\ **Post date:** [July 19, 2010, 10:46pm UTC](https://www.ruby-forum.com/t/code-review-19compat/191863/1 "2010-07-19T22:46:57Z")
tfpt review “/shelveset:19compat;REDMOND\tomat” Comment : Adds LibraryPath19 option. This option allows to set paths to 1.9 libs and is used in -1.9 mode. Implements Kernel#trusted?, Kernel#trust, Kernel#untrust. The flag is always settable and not checked anywhere as we don’t support Ruby’s security model. Fixes Array#fill overload ambiguity. Fixes Array#== and Hash#== to handle recursive structures properly. Tomas ---
**Author:** ![grujildo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/94ad74/32.png) [@grujildo](https://www.ruby-forum.com/u/grujildo)\ **Post date:** [August 20, 2010, 5:38pm UTC](https://www.ruby-forum.com/t/code-review-19compat/191863/2 "2010-08-20T17:38:22Z")
I know I’m a bit late but I have a question. > Implements Kernel#trusted?, Kernel#trust, Kernel#untrust. The flag is always settable and not checked anywhere as we don’t support Ruby’s security model. Since IR doesn’t support Ruby’s security model, does this mean that (for example) it’s really OK to have Object#clone not preserving the untrusted state of an object or having Kernel#trust and Kernel#untrust not raising an exception if an object is frozen, like happen on MRI 1.9? On Mon, Jul 19, 2010 at 22:35, Tomas M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Ironruby-core mailing list > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) – Daniele A. > **[clorophilla.net](https://clorophilla.net/)** [http://twitter.com/JoL1hAHN](http://twitter.com/JoL1hAHN) ---
**Author:** ![grujildo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/94ad74/32.png) [@grujildo](https://www.ruby-forum.com/u/grujildo)\ **Post date:** [August 20, 2010, 6:36pm UTC](https://www.ruby-forum.com/t/code-review-19compat/191863/3 "2010-08-20T18:36:19Z")
The behavior differences you describe should be fixed. This doesn’t mean though that you should base any security related decisions upon flags like tainted and untrusted. We are giving no security guarantees based upon these flags. The only security barriers are those defined by CLR security system. Tomas ---
**Author:** ![grujildo](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/94ad74/32.png) [@grujildo](https://www.ruby-forum.com/u/grujildo)\ **Post date:** [August 20, 2010, 7:27pm UTC](https://www.ruby-forum.com/t/code-review-19compat/191863/4 "2010-08-20T19:27:49Z")
OK thanks. I supposed it was just like for the taint status but the “always settable and not checked anywhere” made me wonder if there was something else. On Fri, Aug 20, 2010 at 18:15, Tomas M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > Â Adds LibraryPath19 option. This option allows to set paths to 1.9 libs and is used in -1.9 mode. > > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) > > * * * > > Ironruby-core mailing list > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [http://rubyforge.org/mailman/listinfo/ironruby-core](http://rubyforge.org/mailman/listinfo/ironruby-core) – Daniele A. > **[clorophilla.net](https://clorophilla.net/)** [http://twitter.com/JoL1hAHN](http://twitter.com/JoL1hAHN)