Wow and I though it was an innocent question. Here is my view
1. Obfuscation doesn't prevent ppl from stealing source. Java has the same problem, there are plenty of great decompilers for java to prove it. 2. Though we understand point 1, "the perception" is that perl being a scripting language creates a "risk" and large companies are risk-averse, which is why large companies prefer java regardless of the lack of security it provides(larry wall doesn't have the same marketing budget as SUN). So if we accept point 1 & 2 we come up with a few interesting questions. 1. If someone is without clue enough to use B::Deparse or B::Deobfuscate, are they also without clue enough to understand that par extracts everything into a temp directory? 2. Will using B::Bytecode and B::ByteLoader provide some level of "obfuscation" above extracting to TMP, and also provide a performance boost? 3. Will using some form of real encryption(DES,3DES,etc.) to the files extracted in TMP provide any more security (beyond perceived) than obfuscation? If you recompile perl58.dll you can do what ever you like with what's in memory, and if you can manipulate memory you have the unencrypted source. 4. Will Perl6+Parrot make PAR obsolete. 5. If 4 is true, how long will it be before perl6 is done (current estimates are 2005-2008), and is anyone willing to wait. >From the little poking around I've done it seems that B::Bytecode is the best direction to go. The work being done with Parrot and Perl6 has very Dramatic performance increases, though it is yet to be determined if Parrot+Perl6 will alleviate the need for PAR. The problem with B::Bytecode for me is that it seems to be very broken on win32 and 5.8.0, and until activestate releases a 5.8.1 build, it will be impractical to do any testing on win32. Until I get 5.8.1 to build on my system I will not be able to do any testing, though it may be worth it for me to test on linux 5.8.1 just to get a feel for what will be required to deal with B::Bytecode and B::ByteLoader, I can't imagine that it will be that hard to introduce a step that takes $pfile and post processes it with B::Bytecode. -jess -----Original Message----- From: Tommy Butler [mailto:[EMAIL PROTECTED] Sent: Saturday, October 18, 2003 4:07 PM To: [EMAIL PROTECTED] Subject: RE: Source Hiding (was: Encyrpting Source) --- "Mr. Lindsay Morris" <[EMAIL PROTECTED]> wrote: > We're getting pretty far off-topic for a PAR list. I think we're very much on topic here. PAR by nature is such a commodity to the great majority of those who use it _because_ they can distribute their code (via PAR) in a manner that isn't as open as pure source files. This discussion is simply touching on an inherent theme (with respect to PAR) that definitely deserves some public discussion. I am excited to have heard from Randall, and the opinions of other Perl hackers are likewise valued. I want to hear what the community has to say about this. Randall (and those of his mindset regarding this issue), would you also avoid purchasing a compiled Perl 6 executable? I believe they can be easily decompiled however using some features from O:: or B:: maybe, though that isn't the point. Friends, please share your views on this matter. This is not flamebait. This is an issue that deserves some attention and I for one want to see what others have to say about this topic and better understand why and where you are using PAR. Thanks. ===== Tommy Butler <[EMAIL PROTECTED]> phone: (817)-468-7716 6711 Forest Park Drive Arlington, TX 76001
