Front page | perl.bootstrap |
Postings from July 2000
Re: Obscuring code?
Thread Previous
|
Thread Next
From:
Chaim Frenkel
Date:
July 25, 2000 18:13
Subject:
Re: Obscuring code?
Message ID:
m3zon5y9r1.fsf@csamnycln01.nyc.csam.com
Unless you make your own lexer/parser, I can't see how you can protect
the source.
Since perl is open a slight change to the lexer would spew out the
entire un-obscured source.
And if all you want is some shrouding write a pre-processor in perl that
would kill the indentation, kill all meaningful variables, and move the
code around.
<chaim>
>>>>> "p" == phil <phil@Stimpy.netroedge.com> writes:
p> I see a method of compiling to a binary or some other means of
p> obscuring code (encryption?) helpful in keeping users from abusing
p> licensing, and as some term it, keeping job security. Most languages
p> don't have an issue with this, but Perl does since it is an
p> 'interpretive' language (OK, well at least from the pov of this
p> discussion). And, I experience most of my code (as a server-side web
p> developer) residing on machines owned and managed by others.
p> Gosh, it would be great if a password or something could get me into
p> the source code and let me modify it directly. Of course, Perl will
p> always have to have access to the source to run. Perhaps some sort of
p> secure dual-key system?? I'm sure some smarter people out there than
p> I can see a solution... or already know of an existing one?! :')
p> In the least, a one-way binary compiler or source code 'scrambler'
p> (obscurator) would handle this, but wouldn't be optimal... perhaps a
p> two-way obscurator which was password based??
p> Thoughts? Comments?
--
Chaim Frenkel Nonlinear Knowledge, Inc.
chaimf@pobox.com +1-718-236-0183
Thread Previous
|
Thread Next