Hi all,
Steffen Mueller wrote:
The big news is that you can now use PAR-generated executables to run
arbitrary external Perl programs as if they were part of the package. If
that sounds to you like a glaring hole with respect to security, then
rest assured that one has to enable the feature manually during packaging:
pp --reusable -o myapp myapp.pl
# works normally
./myapp
# runs otherapp.pl with the library that myapp.pl uses
./myapp --par-options --reuse otherapp.pl
The main reason for this feature is that it's rather common for programs
written in Perl to expect a perl installation to be available. Using the
new feature, it's possible to work around that.
If you wonder why the command line to run another app looks that
obscure, then think twice under which circumstances you would want to do
that... Yes, exactly my thought: Obscure it should be.
The use case that I had in mind for this whole thing unfortunately
requires support for arbitrary perl options. This is much harder to do
than simply running an external script because it'd have to be done from
the C loader (which would have to parse the command line options)
instead of simply patching the par.pl and main.pl loader stages.
Furthermore, this is likely hard or impossible to enable or disable at
packaging time unless we build multiple parl's and extract one according
to whether the feature is desired or not. But down that route lies
madness and I don't plan to go any further in the direction.
Does anybody have an idea how this could be implemented at all? I would
*at least* need the "-c" option which has a profound effect on how the
later bootstrapping stages work (or rather don't in that case).
Cheers,
Steffen
