Re^3: FastCGI and EXEs under Windows
by fizbin (Chaplain) on Oct 27, 2005 at 18:20 UTC
|
CGI::Fast is not the same as FCGI. You'll need both modules. Fortunately, FCGI is available via ppm3. (FCGI implements the low-level bits of the fastcgi protocol; CGI::Fast implements an interface to fastcgi that looks like CGI. CGI::Fast depends on FCGI and uses it internally)
Also, what someone else said about PerlApp with regards to recovering source code. It makes recovery of source code hard - harder than pp, so hard that it can't be done without B::Deparse tricks - but doesn't make it totally impossible.
However, I wouldn't worry about it. Just put into your license text that says that decompiling, disassembling, or reverse engineering the source code is against the license. That's really all you can do.
Frankly, I don't understand the extreme paranoia some people develop with regards to their source code. Maybe I don't code things that are special enough - or sell to clients shady enough - to be that paranoid about it.
--
@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/
| [reply] [d/l] [select] |
|
Many thanks for the clarification! It's much appreciated.
We certainly have a no-decompile/r.e. clause in our contracts. And we trust our clients. But we don't trust some of their other vendors who are competitors in some areas and at times have access to the server. PerlApp makes it that much harder. I don't think it's paranoia.
Another reason for delivering an EXE is so the clients don't have to acquire and install Perl. In our market many many servers are run by people who wouldn't know how to do this or wouldn't want to.
Also it's easier for the clients if we deliver a single EXE than make sure each client is up to date on the 20 scripts that comprise the app.
So there are good arguments for almost anything!
Thanks again. Stephen
| [reply] |
|
Yeah, gotta love the power of pp for that. One exe, no husle, no install required! I love that!
| [reply] |
Re^3: FastCGI and EXEs under Windows
by Anonymous Monk on Oct 27, 2005 at 16:31 UTC
|
Even if they do generate the proper EXE's ... those will not "protect your source code." Get a proper license and some lawyers if you are that paranoid that your code is actually worth stealing. | [reply] |
|
How come? The contents of the EXEs are certainly not readable. Are you saying they can be decompiled?
| [reply] |
|
There's readable and then there's readable. For example, compiled C programs are extremely difficult to decompile - generally if you're going to do that your time would be better spent reimplementing it yourself. But Perl is different. PerlAPP, Perl2EXE and PAR all function, albeit in slightly different ways, by bundling the Perl interpreter and your Perl source code into a single .exe file. This means that with only a moderate amount of work, someone can pick apart that exe and extract the original source - it's not even decompiling at all really. Bearing that in mind, I wholeheartedly agree with the suggestion that what you really need is a solid licensing agreement.
| [reply] |
|
With PerlApp it's much harder to recover source code than it is with other EXE creators (like pp) but it's not totally impossible. The theoretical method (which I've never tried, just had explained to me) is to load the perl-app created tool into an EXE debugger, run the program partway, dump out the memory contents and find where perl put the compiled opcode tree for the script, and then write a perl script that recreates that opcode tree and uses B::Deparse to rip it apart into perl code.
Unless you're implementing state secrets as CGI scripts, it's almost certainly easier for someone trying to obtain your source code to write whatever your script does themselves from scratch than it is for them to extract it out of a PerlApp executeable.
--
@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/
| [reply] [d/l] [select] |
|
|
|
| [reply] |