Bug #110307 for PAR-Packer: Option -F does not encrypt files in inc\lib

Sun Dec 13 11:04:15 2015 joachim.wesenberg [...] gmail.com - Ticket created

Subject:	Option -F does not encrypt files in inc\lib
Date:	Sun, 13 Dec 2015 17:04:03 +0100
To:	bug-PAR-Packer [...] rt.cpan.org
From:	Joachim Wesenberg <joachim.wesenberg [...] gmail.com>

Hallo support team, '.pl'-files ending up in inc\lib are not encrypted using the pp-option '-F'. However, files ending up in inc\scripts are encrypted as expected. pp -f Crypto -F Crypto ...... Windows 10 Strawberry Perl - 5.22.0.1 (64-bit) PAR::Packer - 1.028 pp - 0.992 Thanks very much in advance for your effort fixing the problem. Best regards -- Joachim Wesenberg Stabelsteiner Weg 35 D-61267 Neu-Anspach Germany E-Mail: joachim.wesenberg@gmail.com Phone: +49 6081 42095 Mobile: +49 172 819 65 64

Message body is not shown because sender requested not to inline it.

Sun Dec 13 11:50:48 2015 RSCHUPP [...] cpan.org - Correspondence added

The long option corresponding to -F is called --modfilter for a reason: *.pl files (other than the script to be packed) are categorized (by Module::ScanDeps) as "data", rather than "module". Cheers, Roderich

Sun Dec 13 11:50:49 2015 The RT System itself - Status changed from 'new' to 'open'

Sun Dec 13 11:50:51 2015 RSCHUPP [...] cpan.org - Status changed from 'open' to 'rejected'

Sun Dec 13 12:28:33 2015 joachim.wesenberg [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #110307] Option -F does not encrypt files in inc\lib
Date:	Sun, 13 Dec 2015 18:28:16 +0100
To:	bug-PAR-Packer [...] rt.cpan.org
From:	Joachim Wesenberg <joachim.wesenberg [...] gmail.com>

Roderich, thanks for your quick response. Obviously I interpreted the -F option wrong. Is there any way to encrypt .pl-files which are not considered as "modules" by ScanDeps? The application has a lot of subroutines which are included using 'do' as separate .pl-files by the main script. If there is any smart way or workaround - please let me know. Thanks again Joachim Wesenberg Stabelsteiner Weg 35 D-61267 Neu-Anspach Germany E-Mail: joachim.wesenberg@gmail.com Phone: +49 6081 42095 Mobile: +49 172 819 65 64 Am 13.12.2015 um 17:50 schrieb Roderich Schupp via RT: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=110307 > > > The long option corresponding to -F is called --modfilter for a reason: *.pl files (other than the script to be packed) are categorized (by Module::ScanDeps) as "data", rather than "module". > > Cheers, Roderich

Message body is not shown because sender requested not to inline it.

Sun Dec 13 13:12:02 2015 RSCHUPP [...] cpan.org - Correspondence added

On 2015-12-13 12:28:33, joachim.wesenberg@gmail.com wrote: It's more that the docs are Is there any way to encrypt .pl-files which are not considered Show quoted text

> as > "modules" by ScanDeps? The application has a lot of subroutines which > are included using 'do' as separate .pl-files by the main script. > > If there is any smart way or workaround - please let me know.

The easiest solution is to patch your version of PAR/Packer.pm like this: --- lib/PAR/Packer.pm.orig 2015-11-19 10:07:42.016710501 +0100 +++ lib/PAR/Packer.pm 2015-12-13 18:50:00.188377284 +0100 @@ -813,7 +813,7 @@ $self->_vprint(2, "... adding $map{$pfile} as ${root}lib/$pfile"); - if ($text{$pfile} or $pfile =~ /utf8_heavy\.pl$/i) { + if ($text{$pfile} or $pfile =~ /\.pl$/i) { my $content_ref = $mod_filter->($map{$pfile}, $pfile); $full_manifest->{ $root . "lib/$pfile" } = I could do this in general, but I'm not sure about the consequences: if someone was using "pp -F Crypt .." with non-script .pl files before, this might break if she was accessing the .pl files with something that doesn't ultimately result in a do(). Another solution would be to rename all your .pl file to .al (and change all do() statements accordingly), since Module::ScanDeps classifies these as "autoload" and PAR::Packer treats "autoload" the same as "module". Actually, I like this one better, since that's what your application is doing, it just uses a similar approach as AutoSplit. Cheers, Roderich

Sun Dec 13 13:35:16 2015 joachim.wesenberg [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #110307] Option -F does not encrypt files in inc\lib
Date:	Sun, 13 Dec 2015 19:34:56 +0100
To:	bug-PAR-Packer [...] rt.cpan.org
From:	Joachim Wesenberg <joachim.wesenberg [...] gmail.com>

Roderich, I never thought about the '.al'-solution but now I definitely will follow your suggestion. That helped me quite a lot. Thanks and best regards Jo Am 13.12.2015 19:12 schrieb "Roderich Schupp via RT" < bug-PAR-Packer@rt.cpan.org>: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=110307 > > > On 2015-12-13 12:28:33, joachim.wesenberg@gmail.com wrote: > It's more that the docs are > Is there any way to encrypt .pl-files which are not considered

> > as > > "modules" by ScanDeps? The application has a lot of subroutines which > > are included using 'do' as separate .pl-files by the main script. > > > > If there is any smart way or workaround - please let me know.

> > The easiest solution is to patch your version of PAR/Packer.pm like this: > > --- lib/PAR/Packer.pm.orig 2015-11-19 10:07:42.016710501 +0100 > +++ lib/PAR/Packer.pm 2015-12-13 18:50:00.188377284 +0100 > @@ -813,7 +813,7 @@ > > $self->_vprint(2, "... adding $map{$pfile} as ${root}lib/$pfile"); > > - if ($text{$pfile} or $pfile =~ /utf8_heavy\.pl$/i) { > + if ($text{$pfile} or $pfile =~ /\.pl$/i) { > my $content_ref = $mod_filter->($map{$pfile}, $pfile); > > $full_manifest->{ $root . "lib/$pfile" } = > > > I could do this in general, but I'm not sure about the consequences: if > someone was using "pp -F Crypt .." with non-script .pl files before, this > might break if she was accessing the .pl files with something that doesn't > ultimately result in a do(). > > Another solution would be to rename all your .pl file to .al (and change > all do() statements accordingly), since Module::ScanDeps classifies these > as "autoload" and PAR::Packer treats "autoload" the same as "module". > Actually, I like this one better, since that's what your application is > doing, it just uses a similar approach as AutoSplit. > > Cheers, Roderich > > > > >