P
PerlFAQ Server
This is an excerpt from the latest version perlfaq3.pod, which
comes with the standard Perl distribution. These postings aim to
reduce the number of repeated questions as well as allow the community
to review and update the answers. The latest version of the complete
perlfaq is at http://faq.perl.org .
--------------------------------------------------------------------
3.20: How can I hide the source for my Perl program?
Delete it. Seriously, there are a number of (mostly unsatisfactory)
solutions with varying levels of "security".
First of all, however, you *can't* take away read permission, because
the source code has to be readable in order to be compiled and
interpreted. (That doesn't mean that a CGI script's source is readable
by people on the web, though--only by people with access to the
filesystem.) So you have to leave the permissions at the socially
friendly 0755 level.
Some people regard this as a security problem. If your program does
insecure things and relies on people not knowing how to exploit those
insecurities, it is not secure. It is often possible for someone to
determine the insecure things and exploit them without viewing the
source. Security through obscurity, the name for hiding your bugs
instead of fixing them, is little security indeed.
You can try using encryption via source filters (Starting from Perl 5.8
the Filter::Simple and Filter::Util::Call modules are included in the
standard distribution), but any decent programmer will be able to
decrypt it. You can try using the byte code compiler and interpreter
described later in perlfaq3, but the curious might still be able to
de-compile it. You can try using the native-code compiler described
later, but crackers might be able to disassemble it. These pose varying
degrees of difficulty to people wanting to get at your code, but none
can definitively conceal it (true of every language, not just Perl).
It is very easy to recover the source of Perl programs. You simply feed
the program to the perl interpreter and use the modules in the B::
hierarchy. The B:eparse module should be able to defeat most attempts
to hide source. Again, this is not unique to Perl.
If you're concerned about people profiting from your code, then the
bottom line is that nothing but a restrictive license will give you
legal security. License your software and pepper it with threatening
statements like "This is unpublished proprietary software of XYZ Corp.
Your access to it does not give you permission to use it blah blah
blah." We are not lawyers, of course, so you should see a lawyer if you
want to be sure your license's wording will stand up in court.
--------------------------------------------------------------------
The perlfaq-workers, a group of volunteers, maintain the perlfaq. They
are not necessarily experts in every domain where Perl might show up,
so please include as much information as possible and relevant in any
corrections. The perlfaq-workers also don't have access to every
operating system or platform, so please include relevant details for
corrections to examples that do not work on particular platforms.
Working code is greatly appreciated.
If you'd like to help maintain the perlfaq, see the details in
perlfaq.pod.
comes with the standard Perl distribution. These postings aim to
reduce the number of repeated questions as well as allow the community
to review and update the answers. The latest version of the complete
perlfaq is at http://faq.perl.org .
--------------------------------------------------------------------
3.20: How can I hide the source for my Perl program?
Delete it. Seriously, there are a number of (mostly unsatisfactory)
solutions with varying levels of "security".
First of all, however, you *can't* take away read permission, because
the source code has to be readable in order to be compiled and
interpreted. (That doesn't mean that a CGI script's source is readable
by people on the web, though--only by people with access to the
filesystem.) So you have to leave the permissions at the socially
friendly 0755 level.
Some people regard this as a security problem. If your program does
insecure things and relies on people not knowing how to exploit those
insecurities, it is not secure. It is often possible for someone to
determine the insecure things and exploit them without viewing the
source. Security through obscurity, the name for hiding your bugs
instead of fixing them, is little security indeed.
You can try using encryption via source filters (Starting from Perl 5.8
the Filter::Simple and Filter::Util::Call modules are included in the
standard distribution), but any decent programmer will be able to
decrypt it. You can try using the byte code compiler and interpreter
described later in perlfaq3, but the curious might still be able to
de-compile it. You can try using the native-code compiler described
later, but crackers might be able to disassemble it. These pose varying
degrees of difficulty to people wanting to get at your code, but none
can definitively conceal it (true of every language, not just Perl).
It is very easy to recover the source of Perl programs. You simply feed
the program to the perl interpreter and use the modules in the B::
hierarchy. The B:eparse module should be able to defeat most attempts
to hide source. Again, this is not unique to Perl.
If you're concerned about people profiting from your code, then the
bottom line is that nothing but a restrictive license will give you
legal security. License your software and pepper it with threatening
statements like "This is unpublished proprietary software of XYZ Corp.
Your access to it does not give you permission to use it blah blah
blah." We are not lawyers, of course, so you should see a lawyer if you
want to be sure your license's wording will stand up in court.
--------------------------------------------------------------------
The perlfaq-workers, a group of volunteers, maintain the perlfaq. They
are not necessarily experts in every domain where Perl might show up,
so please include as much information as possible and relevant in any
corrections. The perlfaq-workers also don't have access to every
operating system or platform, so please include relevant details for
corrections to examples that do not work on particular platforms.
Working code is greatly appreciated.
If you'd like to help maintain the perlfaq, see the details in
perlfaq.pod.