Jon, I've been doing some thinking along these lines (for website security, not for releasing code). I don't have a solution, but below are some thoughts I've had. I would love to hear from anyone who knows solutions for any of the points below. Most of the thoughts below are based on encryption, as I don't believe that obfuscating or compiling offer any real security for an attacker who is determined.
For Apache::Registry (or Apache::PerlRun) scripts, it should be fairly trivial to write an Apache::RegistryEncrypt, based on Apache::RegistryNG, that would first decrypt a source file during compile using a public key stored in a (presumably) safe location before turning it into a module. The secret key could be stored on a different (development) server and not be accessible, which would give you fairly good security, both for reading and writing. Unfortunately, this would not protect modules (particularly application modules) which are use'd from these scripts. For modules, it might be possible to write a module which would first decrypt a file before using it (would something using the same type of method as ex::lib::zip* work?). Modules could then be preloaded using PerlModule from the Apache configuration or use lines from a startup.pl file. However, I imagine it might be difficult to decide which modules *have* to be encrypted - if all modules have to be encrypted, that would affect even standard modules, but if it is selectable, there would have to be a way of keeping an attacker from simply placing a module earlier in the @INC path. Maybe something like "everything with the FOOBAR:: prefix has to be encrypted"? The other benefit of this is that the same solution would also work for encrypting true mod_perl handlers, not just scripts. I believe this would be preferable to using a source filter, as a source filter would only protect reading, not writing. Since a source filter operates on everything after the use Filter::Whatever; line, an attacker could simply place code above that line, or replace the file completely and negate any benefit from using it. Besides that, it might be difficult to access a public key from a source filter in a secure manner. For website security, the other solution I considered was to use Apache::RegistryBB or something homebrew which wouldn't check the modification time of a script after the initial compile and use, then simply unmount the filesystem after Apache startup. Of course, like the above solution, this only protects the on-disk copy, the code would still be accessible in memory if debugging was available, etc. Other than that, this just seems like a "clunky" solution, and not very good if the filesystem has to be manually mounted to restart the webserver, but the admin isn't available :-) Thanks, Nathan Byrd * http://search.cpan.org/search?mode=module&query=ex%3A%3Alib%3A%3Azip On Sun, 2002-07-21 at 21:58, Jonathon M. Robison wrote: > Anyone know offhand a good way to hide your perl code when using > mod_perl? Acme::Bleach isn't doing it - httpd is failing to start on > initial test, and then on second test I find that httpd.conf suddenly > got a 'use Acme::Bleach' inserted at line 1 and the whole thing is bleached. > > Perhaps perl2exe? > > --Jon R > >
