Skip Menu |

This queue is for tickets about the Filter-Crypto CPAN distribution.

Report information
The Basics
Id: 102788
Status: resolved
Priority: 0/
Queue: Filter-Crypto

People
Owner: Nobody in particular
Requestors: ZDM [...] cpan.org
Cc: ribasushi [...] leporine.io
AdminCc:

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



Subject: Not compatible with Moo.
Hello. If project use Moo and some of Moo - based package has "lazy" attribute - Filter::Crypto::Decrypt dies with "Can't run with Perl compiler backend". Test code: package BBB; use Moo; # has attr => ( is => 'lazy', init_arg => undef ); require AAA; 1; File AAA.pm is encrypted. Try to uncomment has attr definition.
Thanks for the report and apologies for being so slow responding. I see this was also reported in https://github.com/steve-m-hay/Filter-Crypto/issues/1, where you proposed removing the check on the B:: modules as a fix since the check is easily circumvented anyway. It is already well-known and documented (even in the module's own man pages) that the encryption is relatively easy to get around in various ways. You have found another way that hasn't occurred to me before, but there are also several others, e.g. simply rename the B:: modules to a name that isn't being checked for, or alter the perl interpreter to print out the perl code being fed to it. However, people still find the module helpful in putting hurdles in others people's way to prevent casual access to their source code. I think removing these hurdles make the module less helpful in what it is intended to do, so if anything I am more inclined to find other obstacles to put in people's way rather than take any existing ones away! The solution to using Moo and other modules that load B:: modules is simply to build Filter::Crypto with the -u option to its Makefile.PL. The one and only effect of this option is to do exactly what you have requested -- disable the check on B:: modules. I prefer this to be optional in this way since the check is a moderately useful hurdle which works well for code that doesn't have B:: modules loaded.
I'm closing this ticket since the -u option does indeed fix the example breakage that you gave, and it's already well tested in other scenarios too. Please feel free to re-open it if the -u option doesn't work for you.