Re: (Ovid Security *is* the issue) Re(2): Security, is it to much to ask?

[joefission]

Where are you getting this? Is there a perldoc PerlApp you are looking at?

The ActiveState PDK3.0 docs clearly state the purpose of PerlApp. It Turns your Perl scripts into executables, so that you can run Perl scripts on computers without installing Perl.

Maybe ActiveState stated the security business in previous versions of PerlApp or PDKs. And then again, perhaps they realized the folly of protecting IP. I'm sure they wouldn't want to be liable for someone's IP being compromised using their product.

Please post the relevant documentation so I can understand what you and tachyon are saying. No offense, but I think you guys are getting worked up over a fallacy.

[Ovid]

As lemming pointed out, that was caused by my confusing PerlEx and PerlApp. Once I saw that, I started looking at things a bit closer. PerlEx claims to offer the source code protection. However, all PerlEx does is keep a version of Perl memory-resident and compile the first execution of a Perl/CGI script and save that in memory (see this link for details). The source code is still readily available. Why the heck do they claim source code protection when there is absolutely no attempt to protect the source code?

Now regarding PerlApp, there's no apparent claim that source code is protected. However, since you wish to play Devil's Advocate, why, exactly, would one wish to XOR the source code with a string? This merely adds an unnecessary level of complexity. In fact, the only reason that I could come up with is a naive attempt to hide the source code, which brings us back to tachyon's original post. If you have other theories, I'd love to here them.

Cheers,
Ovid

Vote for paco!

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[joefission]

why, exactly, would one wish to XOR the source code with a string?

I don't know how the internals of PerlApp works. There might be a technical reason for it being XOR, or it might be a hold-over from a previous version that tried to hide source code. But at this point, it doesn't matter...ActiveState's stated intent is not security, but a packaging tool in the present incarnation of PerlApp. Not that it will be like that forever, but it seems like a window of opportunity to figure out how it works and possibly replicate a free version.

Truthfully, I haven't investigated the perl2exe from indigoperl claims of source code protection. The point seems moot because it isn't true as the above discussions point out. IP, in that case, is protected more by threat of lawsuit than technical reasons. PerlEx, the ActiveState product that's like mod_perl for Windows platform web servers. And that is an odd statement about encryption on the product web page.

My apologies for coming off a little over the top, I just couldn't understand what was being said. I consider myself more enlightened at this point, thanks to Ovid.

[lemming]

This may be a PerlApp vs. PerlEx issue

I note that the PerlEx page has the encryption quote. Nothing with PerlApp.

I am curious if the copyright notice "encryption" is on their free version of PerlEx and there may be a better version on their licenced version. (Not curious enough to pay money though)