Greetings, wise ones (humbled, as always, at your presence)
I was wondering how difficult it would be to spike
Perl a bit -- for whatever ghastly reason -- with
some compiled-in encryption capability that would
allow encrypted source files to be decrypted on the
fly and in memory only. Let's call such a crypto-capable
Perl, for reference here, CryPerl (as no doubt the mere
idea would bring tears to the eyes of many a Perl veteran).
When compiling CryPerl (actually, when compiling Perl with the hypothetical cry switch), it would tell me the key
with which to encrypt my source files. Let's say
we use the pgp paradigm and call this the public key.
The private key would be built into the CryPerl binary
and very difficult to discern by studying that binary.
You would start your script #!/usr/local/bin/cryperl
The rest of that script, and your modules if you like (but
not other people's modules, unless they specifically allow
such use) would be encrypted. CryPerl should be easily
able to detect whether a script or a module is plaintext,
and if so, invoke plain old Perl. If if finds an
encrypted file, it would decrypt it, only in memory,
and invoke regular Perl on the decrypted form.
The offender would then be able to distribute her own
particular version of cryperl and her encrypted scripts
and modules and be damned for eternity.
Update: Would it be possible for cryperl to disable Deparse and friends? To make myself clearer, I am trying to pipe-dream about something that the p5p guys would implement. if enabled during perl build, cryperl would be one of two binary outputs of the perl build process (the other one being regular perl). Could underground Deparsing activity conceivably be blocked -- by design, by p5p people -- for cryperl (NOT regular perl, which the perl build would also produce as usual)?
Update: (after a few messages with some very helpful monks) cryperl would not support -d or -M.
Update: Thanks for all the feedback in replies and messages.