I have to second what Chas. is saying here.
The "perl way" doesn't lend itself well ideologically to what you're
attempting to do. If you wanted to hide your source, or create a
proprietary product, maybe perl wasn't the best route for you.
Call it a language, call it a scripting language, anything you call it
implies openness and accessibility.
If you want to hide your work, then do it in a compiled language.
--jms
On Apr 30, 2008, at 1:31 AM, Chas. Owens wrote:
> On Wed, Apr 30, 2008 at 1:11 AM, Anirban Adhikary
> <anirban.adhikary@[EMAIL PROTECTED]
> wrote:
>> Dear list
>> I want to encrypt my perl source code. I am using some modules in
>> my code.
>> Among them some are downloaded from CPAn as well as some are
>> written by my
>> -self. So how to encrypt all perl codes includes the modules.
>>
>> Thanks&Regards in advance
>> Anirban Adhikary
>
> Short answer: It is a bad idea and there is no good way.
>
> Long answer: You can encrypt the source if you want, but if you are
> going to let a user run your code, perl will have to see unencrypted
> code at some point and the user can capture the code at that point.
> You could also obfuscate the code, but this has similar problems. You
> can even recover the source code from PAR archives and executables.
>
> If all you are trying to do is add a hurdle for them to jump take a
> look at PAR* and PAR::Packer**. These have the benefit of adding
> value in addition to making it harder to see the source.
>
> * http://search.cpan.org/dist/PAR/lib/PAR.pm
> ** http://search.cpan.org/dist/PAR-Packer/lib/PAR/Packer.pm
>
>
> --
> Chas. Owens
> wonkden.net
> The most im****tant skill a programmer can have is the ability to read.
>
> --
> To unsubscribe, e-mail: beginners-unsubscribe@[EMAIL PROTECTED]
> For additional commands, e-mail: beginners-help@[EMAIL PROTECTED]
> http://learn.perl.org/
>
>
|
