LanX, I think I got the point but please correct me if not:

• install the hook in @INC to read any required module via a network transfer or even from an array of strings each representing a module.
• do not eval any module at all. Instead eval the executable/test script. For each of its required modules, if not found in @INC will eventually reach the hook sub and get it to load.
• in this way only required modules are eval'ed, the rest wait either in the array of strings (as is the case with me) or at the server if via network.

All this is nice but I omitted one detail: The module files read are encrypted. The user supplies a password at runtime in order to be able to load them. So, with this detail, the trilemma is:

• use the password to decrypt all the modules at once, destroy the password-var, keep the modules in-memory-waiting for the hook to load them whenever needed. Modules stay in the array of strings as plaintext, for the sake of destroying the password-var and also not statically bundling the app with lots of modules.
• store the password in the hook to decrypt module-strings whenever requested. This is the dynamic bundling so-to-speak but with the danger that the password remains in memory for the time of the execution.
• do not use a hook, but decrypt the modules at once, destroy the password, eval ALL the modules (static bundling) before executing the test script, destroy all plaintext module strings - essentially within a a few (critical) seconds.

The last option minimises the danger of memory-dumping the password and the plaintext module strings but does eval all the modules at once (they may not be needed) and then executes the script. The up-side is that modules now reside in the perl interpreter and memory-dumping that will take significantly more effort than memory-dumping a plaintext string variable.

So, I am good+genki with 3rd option (Update: I believe...),

thanks, bliako

The more modules are to be required dynamically the more a @INC hook approach is recommended, because otherwise timing could cause weird side effects .

Regarding your new "encryption" requirement, well good luck...

You seem to believe compiling Perl code makes it unreadable, but I can instantly think of at least three different approaches to deparse op-trees held in memory.

Personally I'd leave the decryption to the hook.

If you are afraid that the decryption key could be read from memory, switch to a algorithm which encrypts the key.

Since your approach is based on secure op-trees, this would be "safe" too. (read: not any more unsafe)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

If you are afraid that the decryption key could be read from memory, switch to a algorithm which encrypts the key.

I know this is not Perl any more but can I ask you if you have handy some pointers for the above? Yes there is XOR or some other obfuscation but the parameters (e.g. XOR operand) must be saved somewhere too... and so on. Just to clarify: I do not need a digest/hash because the actual password must be decoded in order to pass it on to DB for connecting.

Here is a scenario: program needs to connect to DB (many times, not just once). So the first time it runs, it asks the user to supply the password (or even user supplies it via commandline - we know the risk of that). Said program stores password in memory for whenever connecting to DB. Someone (root) does a memory dump of the running process and the password is in there (somewhere). If the password was encrypted somehow then the key will be in the memory dump too (unless it is read from a file etc. but that could prove risky AND expensive). So, the program does not contain the password but when it is run, it must store the password in program memory. How to encrypt that? What do people do in such cases?

bw, bliako (newbie encrypter)