Bug #57797 for Text-MicroMason: Safe-2.27 breaks t/32-safe.t

Do you use the safe_methods feature of Text::MicroMason? I'm afraid that I may have to stop supporting it, or stop supporting it in a truly safe way. I'm not sure if the problem in actual practice is that safe_methods doesn't work, or if the problem is that some tests fail and they need to stop yelling. It's hard to know what to do with this without knowing how it is being used. But I think it will be very hard or impossible to get safe_methods to work within the new version of Safe, since safe_methods isn't actually very safe. Thanks, Alan On Tue, 25 May 2010, ntyni@iki.fi via RT wrote: Show quoted text

I'm not sure if it's a great idea to add a dependency to Safe::Hole by default. If it's possible to use Safe::Hole optionally and only if you use safe_methods, that would be preferrred. Safe::Hole does seem to pass tests with the latest Safe, but I'm not sure if it actually works or not, yet. Alan On Tue, 25 May 2010, simonm@cavalletto.org via RT wrote: Show quoted text

Reading the Safe::Hole pod: It works with the new Safe, but it doesn't do what we want. Specifically, although I'm not sure I'm interpreting it correctly, this seems to be the crux: DESCRIPTION We can call outside defined subroutines from the Safe compartment using share(), or can call methods through the object that is copied into the Safe compartment using varglob(). But that subroutines or methods are executed in the Safe compartment too, so they cannot call another subroutines that are dinamically qualified with the package name such as class methods nor can they compile code that uses opcodes that are forbidden within the compartment. That is: Safe::Hole lets the Safe compartment see things outside the Safe compartment (just like share/varglob/share_from), but those things are still executed inside the safe compartment. This won't do what we want. I've tried directly using Safe's share() on the internal safe_facade coderefs which the new Safe is wrapping with "wrap_code_refs_within" but that does nothing useful, as expected, since sharing still doesn't allow code outside the Safe compartment to be called. The basic limitation here is: the entire package code for $m is unavailable inside the Safe compartment, therefore we can't call any class methods of $m within the compartment. I don't see any easy way around this. The old safe_facade arguably took advantage of a bug in Safe to work the way it did. If we wrapped the entire class structure inside the safe compartment, we could give access to $m's class hierarchy within the Safe. However, not only is this a huge undertaking, it's also the direct opposite of safe. This would allow execution of all methods defined in that class hierarchy and not only the ones that are deemed safe_methods. The only option I can see at this point is deprecating the safe_methods parameter, and disallow the use of $m within a Safe MicroMason template call. I'm open to ideas, but I am likely to implement this unfortunately draconian restriction unless a better path is revealed. Thanks, Alan

I just uploaded Text::MicroMason version 2.10. This version deprecates safe_methods, and skips tests related to it. Pod is updated with a brief description of why the deprecation was necessary. If anyone can find a suitable patch for this I will accept it, but it seems that the older versions of MicroMason were taking advantage of a bug in Safe to provide safe_methods. Thanks, Alan

This is fixed in Text::MicroMason 2.10. A bug in Safe.pm causes the Safe 2.27 test suite to fail under Perl 5.13.1 and Perl 5.13.2; that bug also causes MicroMason to fail t/32 and t/85. That can be dealt with in a separate ticket, if a patched Safe.pm doesn't fix it. Alan