fenLisesi has asked for the wisdom of the Perl Monks concerning the following question:
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.