RonW, the first method did not work, it does not ask me for a password but it exits silently instead. I couldn't find whether pp "extractor" code can be user-specific and couldn't see where in PAR modules the extractor code is. Any pointers on that welcome.

For the second method you suggested, it should work but I am in Linux and still looking for 7z's "extractor.exe" linux-equivalent. But it looks like it is going to fly... alternatively, following your model, I can always make a self-extracting archive linux-style, I am the only one needing to run this, as I do not trust this code with hosting companies. But if a hosting company has a wizard who could sneak onto the temp extracted PAR files, then let it be, it's not the end of the world.

thanks,bliako

It doesn't solve your problem, but if you decide to roll your own solution, you might want to look at this node. I did that after reading this thread because I was curious how something like what you're asking for would work.

kschwab, I have seen what you posted here: Encrypting Source Filter. Thanks!

It makes very clear what one has to do to achieve what I wanted, re: encryption and file contents eval. Also, by asking for a password to decrypt, it avoids saving the password in the file (like Module::Crypt does) which would be plain trivial to extract even without brute-forcing!

Based on your example, I will try to roll my own solution which will address one more concern I have: including (own) modules. All by specifying a single password. And also add a feature to load from net as well as from local file. I wanted to make the spec clearer in my mind before leaving an answer to your post.

On the other hand, I do not want to make too much noise out of this, maybe even placing this post was too much AFAIC, because I see code encryption like administrating hemlock for treating a very special case but can soon spread into mass hysteria.

The only weakness to this method is that one can attach to the script process and make a memory dump. With all modules loaded in memory, it would be easy to figure out the encrypted code and its structure. But if a hosting company takes such an effort to peek on my code then I would lick my wounds and put it on my CV!

bw, bliako

It's a trade-off between complexity and using short lifetime temp files. Even using a source filter to on-the-fly decrypt encrypted Perl source will leave traces of the unencrypted source on the target system. I don't know how much risk bliako is willing to tolerate.

Offhand, I can think of 2 other possibilities:

Use pp to create the executable without encryption, then encrypt the result. To run the program, create a program or script that decrypts the encrypted executable, runs it, then cleans up.

If there is an acceptable Perl installation on the target system, use pp to create a PAR file, then encrypt the PAR file. In that case, create a program to decrypt the PAR file, run it. then clean up.

Thanks RonW, I finally resorted to something like this but with my own 'PAR' which is basically a tar file with encrypted modules, which are decrypted in memory and eval'ed

UPDATE: some discussion on module eval'ing regarding this issue: use of already eval()ed module (from string)