Obfuscating mod_perl code
am 01.02.2005 06:33:43 von DekeIs there a way to obfuscate perl code that runs in apache and mod_perl
and mason etc..?
Thanks!
Is there a way to obfuscate perl code that runs in apache and mod_perl
and mason etc..?
Thanks!
Just put all of your secret code in modules and keep them out of the
path that might be exposed to the web. Are you afraid that maybe the
root user of a server that you do not own might steal your ideas? You
could wait for Perl6 where you can compile your code to byte code which
will be harder to read. Or, just re-use other people's publicly
available code in modules so you don't have anything to be stolen.
Just be happy you are not writing complex, valuable javascript. You
really can't hide it at all.
wana
Just put all of your secret code in modules and keep them out of the
path that might be exposed to the web. Are you afraid that maybe the
root user of a server that you do not own might steal your ideas? You
could wait for Perl6 where you can compile your code to byte code which
will be harder to read. Or, just re-use other people's publicly
available code in modules so you don't have anything to be stolen.
Just be happy you are not writing complex, valuable javascript. You
really can't hide it at all.
wana
Just put all of your secret code in modules and keep them out of the
path that might be exposed to the web. Are you afraid that maybe the
root user of a server that you do not own might steal your ideas? You
could wait for Perl6 where you can compile your code to byte code which
will be harder to read. Or, just re-use other people's publicly
available code in modules so you don't have anything to be stolen.
Just be happy you are not writing complex, valuable javascript. You
really can't hide it at all.
wana
Ok stealing some code by the root user especially at a hosting site is
definately there. But also I need to hide passwords and access info to
databases as well as other things - so its not just code.
How will compiling in perl work? Can it be decompiled? Can it be
integrated into mod_perl and mason and such?
ioneabu@yahoo.com wrote:
> Just put all of your secret code in modules and keep them out of the
> path that might be exposed to the web. Are you afraid that maybe the
> root user of a server that you do not own might steal your ideas? You
> could wait for Perl6 where you can compile your code to byte code which
> will be harder to read. Or, just re-use other people's publicly
> available code in modules so you don't have anything to be stolen.
>
> Just be happy you are not writing complex, valuable javascript. You
> really can't hide it at all.
>
> wana
>
Ok stealing some code by the root user especially at a hosting site is
definately there. But also I need to hide passwords and access info to
databases as well as other things - so its not just code.
How will compiling in perl work? Can it be decompiled? Can it be
integrated into mod_perl and mason and such?
ioneabu@yahoo.com wrote:
> Just put all of your secret code in modules and keep them out of the
> path that might be exposed to the web. Are you afraid that maybe the
> root user of a server that you do not own might steal your ideas? You
> could wait for Perl6 where you can compile your code to byte code which
> will be harder to read. Or, just re-use other people's publicly
> available code in modules so you don't have anything to be stolen.
>
> Just be happy you are not writing complex, valuable javascript. You
> really can't hide it at all.
>
> wana
>
Ok stealing some code by the root user especially at a hosting site is
definately there. But also I need to hide passwords and access info to
databases as well as other things - so its not just code.
How will compiling in perl work? Can it be decompiled? Can it be
integrated into mod_perl and mason and such?
ioneabu@yahoo.com wrote:
> Just put all of your secret code in modules and keep them out of the
> path that might be exposed to the web. Are you afraid that maybe the
> root user of a server that you do not own might steal your ideas? You
> could wait for Perl6 where you can compile your code to byte code which
> will be harder to read. Or, just re-use other people's publicly
> available code in modules so you don't have anything to be stolen.
>
> Just be happy you are not writing complex, valuable javascript. You
> really can't hide it at all.
>
> wana
>
Deke wrote:
> Ok stealing some code by the root user especially at a hosting site is
> definately there. But also I need to hide passwords and access info to
> databases as well as other things - so its not just code.
1. Don't top-post.
2. Don't store "valuable" information in Perl scripts/modules.
--
Tore Aursand
"Nothing is certain but death and taxes. Of the two, taxes happen
annually." (Joel Fox)
Deke wrote:
> Ok stealing some code by the root user especially at a hosting site is
> definately there. But also I need to hide passwords and access info to
> databases as well as other things - so its not just code.
1. Don't top-post.
2. Don't store "valuable" information in Perl scripts/modules.
--
Tore Aursand
"Nothing is certain but death and taxes. Of the two, taxes happen
annually." (Joel Fox)
Deke wrote:
> Ok stealing some code by the root user especially at a hosting site is
> definately there. But also I need to hide passwords and access info to
> databases as well as other things - so its not just code.
1. Don't top-post.
2. Don't store "valuable" information in Perl scripts/modules.
--
Tore Aursand
"Nothing is certain but death and taxes. Of the two, taxes happen
annually." (Joel Fox)
Where does one store database access passwords for scripts? Almost every
instance I have seen, they were stored in the script itself.
Tore Aursand wrote:
> Deke wrote:
>
>> Ok stealing some code by the root user especially at a hosting site is
>> definately there. But also I need to hide passwords and access info to
>> databases as well as other things - so its not just code.
>
>
> 1. Don't top-post.
> 2. Don't store "valuable" information in Perl scripts/modules.
>
>
Where does one store database access passwords for scripts? Almost every
instance I have seen, they were stored in the script itself.
Tore Aursand wrote:
> Deke wrote:
>
>> Ok stealing some code by the root user especially at a hosting site is
>> definately there. But also I need to hide passwords and access info to
>> databases as well as other things - so its not just code.
>
>
> 1. Don't top-post.
> 2. Don't store "valuable" information in Perl scripts/modules.
>
>
Where does one store database access passwords for scripts? Almost every
instance I have seen, they were stored in the script itself.
Tore Aursand wrote:
> Deke wrote:
>
>> Ok stealing some code by the root user especially at a hosting site is
>> definately there. But also I need to hide passwords and access info to
>> databases as well as other things - so its not just code.
>
>
> 1. Don't top-post.
> 2. Don't store "valuable" information in Perl scripts/modules.
>
>
"Deke"
news:10vvbhj3pa8j344@news.supernews.com...
> Where does one store database access passwords for scripts? Almost every
> instance I have seen, they were stored in the script itself.
please dont ignore this bit of info:
> > 1. Don't top-post.
> > 2. Don't store "valuable" information in Perl scripts/modules.
I store config opts in an XML file and write a module that uses XML::XPath
to get the data:
use warnings;
use strict;
package NWS::DBI;
use base q|Class::DBI|;
our $driver = myWeatherConfig->driver;
our $database = myWeatherConfig->source;
our $dsn = "DBI:$driver:$database";
our $user = myWeatherConfig->user;
our $pass = myWeatherConfig->pass;
__PACKAGE__->connection( $dsn, $user, $pass );
1;
Make the file readable only by you, and then only you and root can get in
the file. If you are scared root will steal the info, you need your own
machine where you are root. If you are scared someone will boot the machine
with a rescue disk and steal the data, you need to lock the machine in a
closet. If you are scared someone will break in the closet... ;0)
Todd W.
> Tore Aursand wrote:
> > Deke wrote:
> >
> >> Ok stealing some code by the root user especially at a hosting site is
> >> definately there. But also I need to hide passwords and access info to
> >> databases as well as other things - so its not just code.
> >
> >
> >
> >
"Deke"
news:10vvbhj3pa8j344@news.supernews.com...
> Where does one store database access passwords for scripts? Almost every
> instance I have seen, they were stored in the script itself.
please dont ignore this bit of info:
> > 1. Don't top-post.
> > 2. Don't store "valuable" information in Perl scripts/modules.
I store config opts in an XML file and write a module that uses XML::XPath
to get the data:
use warnings;
use strict;
package NWS::DBI;
use base q|Class::DBI|;
our $driver = myWeatherConfig->driver;
our $database = myWeatherConfig->source;
our $dsn = "DBI:$driver:$database";
our $user = myWeatherConfig->user;
our $pass = myWeatherConfig->pass;
__PACKAGE__->connection( $dsn, $user, $pass );
1;
Make the file readable only by you, and then only you and root can get in
the file. If you are scared root will steal the info, you need your own
machine where you are root. If you are scared someone will boot the machine
with a rescue disk and steal the data, you need to lock the machine in a
closet. If you are scared someone will break in the closet... ;0)
Todd W.
> Tore Aursand wrote:
> > Deke wrote:
> >
> >> Ok stealing some code by the root user especially at a hosting site is
> >> definately there. But also I need to hide passwords and access info to
> >> databases as well as other things - so its not just code.
> >
> >
> >
> >
"Deke"
news:10vvbhj3pa8j344@news.supernews.com...
> Where does one store database access passwords for scripts? Almost every
> instance I have seen, they were stored in the script itself.
please dont ignore this bit of info:
> > 1. Don't top-post.
> > 2. Don't store "valuable" information in Perl scripts/modules.
I store config opts in an XML file and write a module that uses XML::XPath
to get the data:
use warnings;
use strict;
package NWS::DBI;
use base q|Class::DBI|;
our $driver = myWeatherConfig->driver;
our $database = myWeatherConfig->source;
our $dsn = "DBI:$driver:$database";
our $user = myWeatherConfig->user;
our $pass = myWeatherConfig->pass;
__PACKAGE__->connection( $dsn, $user, $pass );
1;
Make the file readable only by you, and then only you and root can get in
the file. If you are scared root will steal the info, you need your own
machine where you are root. If you are scared someone will boot the machine
with a rescue disk and steal the data, you need to lock the machine in a
closet. If you are scared someone will break in the closet... ;0)
Todd W.
> Tore Aursand wrote:
> > Deke wrote:
> >
> >> Ok stealing some code by the root user especially at a hosting site is
> >> definately there. But also I need to hide passwords and access info to
> >> databases as well as other things - so its not just code.
> >
> >
> >
> >
Deke wrote:
>>> Ok stealing some code by the root user especially at a hosting site
>>> is definately there. But also I need to hide passwords and access
>>> info to databases as well as other things - so its not just code.
>> 1. Don't top-post.
>> 2. Don't store "valuable" information in Perl scripts/modules.
> Where does one store database access passwords for scripts?
Why do you continue top-posting when I tell you not to?
> Almost every instance I have seen, they were stored in the script itself.
Doesn't that sound weird? I mean - everyone with access to the script
can read them, right? Does that sound safe? No, I didn't think so.
Store the passwords encrypted in the storage backend, ie. the database
or something. That way it'll at least be _more_ secure. The rest of the
security depends on a whole lot of other things, though.
--
Tore Aursand
"War is too serious a matter to entrust to military men." (Georges
Clemenceau)
Deke wrote:
>>> Ok stealing some code by the root user especially at a hosting site
>>> is definately there. But also I need to hide passwords and access
>>> info to databases as well as other things - so its not just code.
>> 1. Don't top-post.
>> 2. Don't store "valuable" information in Perl scripts/modules.
> Where does one store database access passwords for scripts?
Why do you continue top-posting when I tell you not to?
> Almost every instance I have seen, they were stored in the script itself.
Doesn't that sound weird? I mean - everyone with access to the script
can read them, right? Does that sound safe? No, I didn't think so.
Store the passwords encrypted in the storage backend, ie. the database
or something. That way it'll at least be _more_ secure. The rest of the
security depends on a whole lot of other things, though.
--
Tore Aursand
"War is too serious a matter to entrust to military men." (Georges
Clemenceau)
Deke wrote:
>>> Ok stealing some code by the root user especially at a hosting site
>>> is definately there. But also I need to hide passwords and access
>>> info to databases as well as other things - so its not just code.
>> 1. Don't top-post.
>> 2. Don't store "valuable" information in Perl scripts/modules.
> Where does one store database access passwords for scripts?
Why do you continue top-posting when I tell you not to?
> Almost every instance I have seen, they were stored in the script itself.
Doesn't that sound weird? I mean - everyone with access to the script
can read them, right? Does that sound safe? No, I didn't think so.
Store the passwords encrypted in the storage backend, ie. the database
or something. That way it'll at least be _more_ secure. The rest of the
security depends on a whole lot of other things, though.
--
Tore Aursand
"War is too serious a matter to entrust to military men." (Georges
Clemenceau)
Tore Aursand
> Deke wrote:
> >>> Ok stealing some code by the root user especially at a hosting site
> >>> is definately there. But also I need to hide passwords and access
> >>> info to databases as well as other things - so its not just code.
>
> >> 1. Don't top-post.
> >> 2. Don't store "valuable" information in Perl scripts/modules.
>
> > Where does one store database access passwords for scripts?
>
> Why do you continue top-posting when I tell you not to?
>
> > Almost every instance I have seen, they were stored in the script
> > itself.
>
> Doesn't that sound weird? I mean - everyone with access to the script
> can read them, right? Does that sound safe? No, I didn't think so.
Letting people you don't trust have access to the script doesn't sound
safe, either. Passwords or no.
>
> Store the passwords encrypted in the storage backend, ie. the database
> or something. That way it'll at least be _more_ secure. The rest of the
> security depends on a whole lot of other things, though.
You recommend storing the passwords to the database within the database?
Why not just encase the computer in cement and drop into the Mariana's
trench. Much more secure, and just as useful.
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
Tore Aursand
> Deke wrote:
> >>> Ok stealing some code by the root user especially at a hosting site
> >>> is definately there. But also I need to hide passwords and access
> >>> info to databases as well as other things - so its not just code.
>
> >> 1. Don't top-post.
> >> 2. Don't store "valuable" information in Perl scripts/modules.
>
> > Where does one store database access passwords for scripts?
>
> Why do you continue top-posting when I tell you not to?
>
> > Almost every instance I have seen, they were stored in the script
> > itself.
>
> Doesn't that sound weird? I mean - everyone with access to the script
> can read them, right? Does that sound safe? No, I didn't think so.
Letting people you don't trust have access to the script doesn't sound
safe, either. Passwords or no.
>
> Store the passwords encrypted in the storage backend, ie. the database
> or something. That way it'll at least be _more_ secure. The rest of the
> security depends on a whole lot of other things, though.
You recommend storing the passwords to the database within the database?
Why not just encase the computer in cement and drop into the Mariana's
trench. Much more secure, and just as useful.
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
Tore Aursand
> Deke wrote:
> >>> Ok stealing some code by the root user especially at a hosting site
> >>> is definately there. But also I need to hide passwords and access
> >>> info to databases as well as other things - so its not just code.
>
> >> 1. Don't top-post.
> >> 2. Don't store "valuable" information in Perl scripts/modules.
>
> > Where does one store database access passwords for scripts?
>
> Why do you continue top-posting when I tell you not to?
>
> > Almost every instance I have seen, they were stored in the script
> > itself.
>
> Doesn't that sound weird? I mean - everyone with access to the script
> can read them, right? Does that sound safe? No, I didn't think so.
Letting people you don't trust have access to the script doesn't sound
safe, either. Passwords or no.
>
> Store the passwords encrypted in the storage backend, ie. the database
> or something. That way it'll at least be _more_ secure. The rest of the
> security depends on a whole lot of other things, though.
You recommend storing the passwords to the database within the database?
Why not just encase the computer in cement and drop into the Mariana's
trench. Much more secure, and just as useful.
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
Deke
> Is there a way to obfuscate perl code that runs in apache and mod_perl
> and mason etc..?
Don't use strict or warnings, and don't declare variables in the smallest
possible scope.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
Deke
> Is there a way to obfuscate perl code that runs in apache and mod_perl
> and mason etc..?
Don't use strict or warnings, and don't declare variables in the smallest
possible scope.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
Post removed (X-No-Archive: yes)
xhoster@gmail.com wrote:
> Letting people you don't trust have access to the script doesn't sound
> safe, either. Passwords or no.
I agree.
>> Store the passwords encrypted in the storage backend, ie. the database
>> or something. That way it'll at least be _more_ secure. The rest of the
>> security depends on a whole lot of other things, though.
> You recommend storing the passwords to the database within the database?
> Why not just encase the computer in cement and drop into the Mariana's
> trench. Much more secure, and just as useful.
I wasn't thinking about the database, but about the part where the OP
mentioned "...to databases as well as other things".
--
Tore Aursand
"What we anticipate seldom occurs. What we least expected generally
happens." (Benjamin Disraeli)
xhoster@gmail.com wrote:
> Letting people you don't trust have access to the script doesn't sound
> safe, either. Passwords or no.
I agree.
>> Store the passwords encrypted in the storage backend, ie. the database
>> or something. That way it'll at least be _more_ secure. The rest of the
>> security depends on a whole lot of other things, though.
> You recommend storing the passwords to the database within the database?
> Why not just encase the computer in cement and drop into the Mariana's
> trench. Much more secure, and just as useful.
I wasn't thinking about the database, but about the part where the OP
mentioned "...to databases as well as other things".
--
Tore Aursand
"What we anticipate seldom occurs. What we least expected generally
happens." (Benjamin Disraeli)
xhoster@gmail.com wrote:
> Letting people you don't trust have access to the script doesn't sound
> safe, either. Passwords or no.
I agree.
>> Store the passwords encrypted in the storage backend, ie. the database
>> or something. That way it'll at least be _more_ secure. The rest of the
>> security depends on a whole lot of other things, though.
> You recommend storing the passwords to the database within the database?
> Why not just encase the computer in cement and drop into the Mariana's
> trench. Much more secure, and just as useful.
I wasn't thinking about the database, but about the part where the OP
mentioned "...to databases as well as other things".
--
Tore Aursand
"What we anticipate seldom occurs. What we least expected generally
happens." (Benjamin Disraeli)
Tore, get some Ritalin or get some sex and calm down.
1. These hosted machines at a hosting site will be root accessible by
the admins there as a matter of policy.
2. Only database access password and login will be in the script. I
don't know how else to do it. That password cannot be stored in the
database. THat is why I posted here.
3. THe database houses the rest of the data. The scripts do not.
4. The scripts are not read accessible by everyone. Regardless, root
will be able to read anything - as in hosting site admins.
Can someone please help here?
Tore Aursand wrote:
> Deke wrote:
> >>> Ok stealing some code by the root user especially at a hosting site
> >>> is definately there. But also I need to hide passwords and access
> >>> info to databases as well as other things - so its not just code.
>
> >> 1. Don't top-post.
> >> 2. Don't store "valuable" information in Perl scripts/modules.
>
>> Where does one store database access passwords for scripts?
>
>
> Why do you continue top-posting when I tell you not to?
>
>> Almost every instance I have seen, they were stored in the script itself.
>
>
> Doesn't that sound weird? I mean - everyone with access to the script
> can read them, right? Does that sound safe? No, I didn't think so.
>
> Store the passwords encrypted in the storage backend, ie. the database
> or something. That way it'll at least be _more_ secure. The rest of the
> security depends on a whole lot of other things, though.
>
>
On 2005-02-02, Deke
> Tore, get some Ritalin or get some sex and calm down.
[snip]
> Can someone please help here?
Probably not, if that's your attitude...
--
David H. Adler -
It's amazing what giant mutant ants that are the result of Man's
dabbling with the power of atomic energy can accomplish when they set
themselves to the task. - Mark Rogaski