Skip Menu |
 

This queue is for tickets about the Text-MicroMason CPAN distribution.

Report information
The Basics
Id: 57797
Status: resolved
Priority: 0/
Queue: Text-MicroMason

People
Owner: FERRENCY [...] cpan.org
Requestors: ntyni [...] iki.fi
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 2.09
Fixed in: (no value)



Subject: Safe-2.27 breaks t/32-safe.t
Download (untitled) / with headers
text/plain 972b
Recent CPAN tester failures, for example this: http://www.cpantesters.org/cpan/report/07267833-b19f-3f77-b713-d32bba55d77f are caused by Safe.pm 2.27, which now wraps code refs returned from reval(). The symptoms are errors like Can't locate package Class::MixinFactory::HasAFactory for @Text::MicroMason::Base::AUTO::Safe_HTMLMason::ISA at blib/lib/Text/MicroMason/Safe.pm line 39. Can't locate package Class::MixinFactory::NEXT for @Text::MicroMason::Base::AUTO::Safe_HTMLMason::ISA at blib/lib/Text/MicroMason/Safe.pm line 39. (in cleanup) MicroMason execution failed: Can't locate object method "execute" via package "Text::MicroMason::Base::AUTO::Safe_HTMLMason" (perhaps you forgot to load "Text::MicroMason::Base::AUTO::Safe_HTMLMason"?) at blib/lib/Text/MicroMason/Safe.pm line 39. As Safe-2.27 is bundled with Perl 5.12.1, this will bite quite many people. Thanks for your work on Text-MicroMason, -- Niko Tyni (Debian Perl Group) ntyni@debian.org
Subject: Re: [rt.cpan.org #57797] Safe-2.27 breaks t/32-safe.t
Date: Mon, 24 May 2010 17:15:51 -0400 (EDT)
To: "ntyni [...] iki.fi via RT" <bug-Text-MicroMason [...] rt.cpan.org>
From: alan [...] ferrency.com
Hi, The limitation I'm facing here seems to be that code executed within a Safe compartment doesn't seem to be able to call methods on objects that are stored in lexical variables (in this case, variables lexically enclosed within a coderef). It looks like those objects can't see any of the code in packages they're supposed to be inheriting from. The intent of the MicroMason code that was broken here is to expose only a limited subset of an object's methods to the interior of the Safe container. Do you know if there is any official way to do this correctly with Safe? I'm sorry I didn't pay attention to these bug reports earlier, I forgot that 5.12 was actually released :) Thanks for your help, Alan On Mon, 24 May 2010, ntyni@iki.fi via RT wrote: Show quoted text
> Mon May 24 07:50:36 2010: Request 57797 was acted upon. > Transaction: Ticket created by ntyni@iki.fi > Queue: Text-MicroMason > Subject: Safe-2.27 breaks t/32-safe.t > Broken in: 2.09 > Severity: Important > Owner: Nobody > Requestors: ntyni@iki.fi > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=57797 > > > > Recent CPAN tester failures, for example this: > > http://www.cpantesters.org/cpan/report/07267833-b19f-3f77-b713-d32bba55d77f > > are caused by Safe.pm 2.27, which now wraps code refs returned from reval(). > > The symptoms are errors like > > Can't locate package Class::MixinFactory::HasAFactory for > @Text::MicroMason::Base::AUTO::Safe_HTMLMason::ISA at > blib/lib/Text/MicroMason/Safe.pm line 39. > Can't locate package Class::MixinFactory::NEXT for > @Text::MicroMason::Base::AUTO::Safe_HTMLMason::ISA at > blib/lib/Text/MicroMason/Safe.pm line 39. > (in cleanup) MicroMason execution failed: Can't locate object > method "execute" via package > "Text::MicroMason::Base::AUTO::Safe_HTMLMason" (perhaps you forgot to > load "Text::MicroMason::Base::AUTO::Safe_HTMLMason"?) at > blib/lib/Text/MicroMason/Safe.pm line 39. > > > As Safe-2.27 is bundled with Perl 5.12.1, this will bite quite many people. > > Thanks for your work on Text-MicroMason, > -- > Niko Tyni (Debian Perl Group) > ntyni@debian.org >
Subject: Re: [rt.cpan.org #57797] Safe-2.27 breaks t/32-safe.t
Date: Tue, 25 May 2010 12:10:56 +0300
To: "alan [...] ferrency.com via RT" <bug-Text-MicroMason [...] rt.cpan.org>
From: Niko Tyni <ntyni [...] iki.fi>
Download (untitled) / with headers
text/plain 896b
On Mon, May 24, 2010 at 05:16:21PM -0400, alan@ferrency.com via RT wrote: Show quoted text
Show quoted text
> The limitation I'm facing here seems to be that code executed within a > Safe compartment doesn't seem to be able to call methods on objects that > are stored in lexical variables (in this case, variables lexically > enclosed within a coderef). It looks like those objects can't see any of > the code in packages they're supposed to be inheriting from. > > The intent of the MicroMason code that was broken here is to expose only > a limited subset of an object's methods to the interior of the Safe > container. Do you know if there is any official way to do this correctly > with Safe?
Sorry, I can't really say offhand, nor can I find a solution easily. I suppose you could ask the Safe maintainer Rafaël Garcia-Suarez. -- Niko Tyni ntyni@debian.org
Subject: Re: [rt.cpan.org #57797] Safe-2.27 breaks t/32-safe.t
Date: Tue, 25 May 2010 11:29:07 -0400 (EDT)
To: "ntyni [...] iki.fi via RT" <bug-Text-MicroMason [...] rt.cpan.org>
From: alan [...] ferrency.com
Download (untitled) / with headers
text/plain 1.5k
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
> Queue: Text-MicroMason > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=57797 > > > On Mon, May 24, 2010 at 05:16:21PM -0400, alan@ferrency.com via RT wrote: >
>> The limitation I'm facing here seems to be that code executed within a >> Safe compartment doesn't seem to be able to call methods on objects that >> are stored in lexical variables (in this case, variables lexically >> enclosed within a coderef). It looks like those objects can't see any of >> the code in packages they're supposed to be inheriting from. >> >> The intent of the MicroMason code that was broken here is to expose only >> a limited subset of an object's methods to the interior of the Safe >> container. Do you know if there is any official way to do this correctly >> with Safe?
> > Sorry, I can't really say offhand, nor can I find a solution easily. > > I suppose you could ask the Safe maintainer Rafaël Garcia-Suarez. > -- > Niko Tyni ntyni@debian.org > > >
Subject: Re: [rt.cpan.org #57797] Safe-2.27 breaks t/32-safe.t
Date: Tue, 25 May 2010 11:39:11 -0400
To: bug-Text-MicroMason [...] rt.cpan.org
From: Matthew Simon Ryan Cavalletto <simonm [...] cavalletto.org>
Download (untitled) / with headers
text/plain 1.1k
On May 24, 2010, at 5:16 PM, alan@ferrency.com via RT wrote: Show quoted text
> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=57797 > > > The limitation I'm facing here seems to be that code executed within a > Safe compartment doesn't seem to be able to call methods on objects that > are stored in lexical variables (in this case, variables lexically > enclosed within a coderef). It looks like those objects can't see any of > the code in packages they're supposed to be inheriting from. > > The intent of the MicroMason code that was broken here is to expose only > a limited subset of an object's methods to the interior of the Safe > container. Do you know if there is any official way to do this correctly > with Safe?
I spent a few minutes looking into this yesterday, and at first glance it looks like Safe::Hole would do what we need: cause the anonymous subroutine references constructed on line 39 of Text::MicroMason::Safe to be executed in the main compartment rather than inside the safe compartment. I haven't used Safe::Hole before, so it'll take some trial and error, and it might turn out that Safe::Hole doesn't work with the latest version of Safe, but other than that it seems workable in theory... -Simon
Subject: Re: [rt.cpan.org #57797] Safe-2.27 breaks t/32-safe.t
Date: Wed, 26 May 2010 13:00:10 -0400 (EDT)
To: "simonm [...] cavalletto.org via RT" <bug-Text-MicroMason [...] rt.cpan.org>
From: alan [...] ferrency.com
Download (untitled) / with headers
text/plain 1.6k
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
> Queue: Text-MicroMason > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=57797 > > > On May 24, 2010, at 5:16 PM, alan@ferrency.com via RT wrote: >
>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=57797 > >> >> The limitation I'm facing here seems to be that code executed within a >> Safe compartment doesn't seem to be able to call methods on objects that >> are stored in lexical variables (in this case, variables lexically >> enclosed within a coderef). It looks like those objects can't see any of >> the code in packages they're supposed to be inheriting from. >> >> The intent of the MicroMason code that was broken here is to expose only >> a limited subset of an object's methods to the interior of the Safe >> container. Do you know if there is any official way to do this correctly >> with Safe?
> > I spent a few minutes looking into this yesterday, and at first glance > it looks like Safe::Hole would do what we need: cause the anonymous > subroutine references constructed on line 39 of Text::MicroMason::Safe > to be executed in the main compartment rather than inside the safe > compartment. > > I haven't used Safe::Hole before, so it'll take some trial and error, > and it might turn out that Safe::Hole doesn't work with the latest > version of Safe, but other than that it seems workable in theory... >
Download (untitled) / with headers
text/plain 965b
On Tue May 25 11:39:21 2010, simonm@cavalletto.org wrote: Show quoted text
> > I spent a few minutes looking into this yesterday, and at first glance > it looks like Safe::Hole would do what we need: cause the anonymous > subroutine references constructed on line 39 of > Text::MicroMason::Safe to be executed in the main compartment > rather than inside the safe compartment. > > I haven't used Safe::Hole before, so it'll take some trial and error, > and it might turn out that Safe::Hole doesn't work with the latest > version of Safe, but other than that it seems workable in theory...
Unfortunately, Safe::Hole just looks like a candy coated Safe::varglob and/or Safe::share. I don't think it'll give us anything that Safe doesn't already provide, except some ease of use if we happen to want to do what Safe::Hole does best. However, I finally have a bit of time to look into this, so I'm going to see if there's anything else I can do about it. Alan
RT-Send-CC: simonm [...] cavalletto.org
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
Download (untitled) / with headers
text/plain 390b
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
Download (untitled) / with headers
text/plain 277b
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.