RE: Mail::Sender modperl.
I MIME::Lite to send messages. It uses your native sendmail install, or you can use it to send to an SMPT port. We actually have Qmail installed and it use the sendmail link Qmail configs and works just fine for about 40k emails a day. -Original Message- From: Richard Clarke [mailto:[EMAIL PROTECTED]] Sent: Saturday, July 20, 2002 8:28 AM To: [EMAIL PROTECTED] Subject: Mail::Sender modperl. List, Have any of you had any problems using Mail::Sender from within mod_perl. My script seems to just sit there waiting for $sender-Open to do anything. I will email the author also but imagined he *might* not be familiar with mod_perl so won't be able to offer any suggestions. Anyone? I looked through the archives but saw no reference to a problem like this. Some people indicated much success with Mail::Sender (not so for me however!). Second, the recommended solution for sending mails is to instead put them on a queue for an external daemon to handle. My question is, is there a standard implementation people use when doing this. Is the KISS theory invoked and the outoing mail simply written to some plain text spool file or do people use something more involved like writing the to,cc,from,subject,body test to a database and storing any temporary files (attachment) in a directory for later encoding? Ric p.s. here is an excerpt from my apache log indicating precisely what happens 220 mail.likewhoa.com ESMTP Postfix 421 Error: timeout exceeded ehlo localhost mail from: [EMAIL PROTECTED] rcpt to: [EMAIL PROTECTED] data To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] X-Mailer: Perl script null using Mail::Sender 0.7.14.1 by Jenda Krynicky running on localhost (127.0.0.1) under account root Date: Sat, 20 Jul 2002 13:18:12 - Message-ID: [EMAIL PROTECTED] Subject: msg msg msg close sender . quit done The request took 305.710375070572 seconds
Re: Hiding perl code
Thanks, Iain! This helps explain some problems I ran into when I tried to use Switch. ;-) Wish the Switch docs included some caveats about using it with mod_perl Wes Sheldahl Iain Truskett [EMAIL PROTECTED] on 07/21/2002 11:10:25 PM To: [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Re: Hiding perl code * Jonathon M. Robison ([EMAIL PROTECTED]) [22 Jul 2002 13:03]: Anyone know offhand a good way to hide your perl code when using mod_perl? Acme::Bleach isn't doing it - httpd is failing to start on initial test [...] Acme::Bleach is a source filter. Source filters will just screw up your mod_perl stuff. IIRC, you get similar problems using Switch and so on. Perhaps perl2exe? Nope. That does weird compiler stuff that will interfere with the fact that Apache's using Perl internally. As far as I know, there's no good way to do it. It is Perl after all. And with mod_perl things just get trickier. Out of interest, why? cheers, -- Iain.
Re: Hiding perl code
-- [EMAIL PROTECTED] on 07/22/02 09:15:23 -0400 Thanks, Iain! This helps explain some problems I ran into when I tried to use Switch. ;-) Wish the Switch docs included some caveats about using it with mod_perl Switch, Multifiles, Q::S, and A::B all have a Caveat Utilitor note in them. It's a bood bet that Damian hasn't tested any of his code with mod_perl. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: Hiding perl code
At my former employer's, we built an Enterprise Management System out of mod_perl. He wants to distribute it to clients w/o risking theft of his code. --Jon R. PGP Key fingerprint = 12 DA FC 06 AB 4C D6 A4 DE 03 E0 77 D6 DE E0 73 PGP public key available by fingering [EMAIL PROTECTED] On Mon, 22 Jul 2002, Iain Truskett wrote: * Jonathon M. Robison ([EMAIL PROTECTED]) [22 Jul 2002 13:03]: Anyone know offhand a good way to hide your perl code when using mod_perl? Acme::Bleach isn't doing it - httpd is failing to start on initial test [...] Acme::Bleach is a source filter. Source filters will just screw up your mod_perl stuff. IIRC, you get similar problems using Switch and so on. Perhaps perl2exe? Nope. That does weird compiler stuff that will interfere with the fact that Apache's using Perl internally. As far as I know, there's no good way to do it. It is Perl after all. And with mod_perl things just get trickier. Out of interest, why? cheers, -- Iain.
Re: Hiding perl code
At my former employer's, we built an Enterprise Management System out of mod_perl. He wants to distribute it to clients w/o risking theft of his code. If w/o risking theft means eliminating risk of theft, then he can't do it. He can lower risk to some degree, but it can't be eliminated. See http://www.perldoc.com/perl5.6/pod/perlfaq3.html#How-can-I-hide-the-source-for-my-Perl-program- xoxo, Andy -- 'Andy Lester[EMAIL PROTECTED] Programmer/author petdance.com Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$) [unpack'C*',n2]3%+\34.'%.'^%4+!o.'])
Re: Hiding perl code
Hi!
On Sun, Jul 21, 2002 at 10:58:24PM -0400, Jonathon M. Robison wrote:
Anyone know offhand a good way to hide your perl code when using
mod_perl? Acme::Bleach isn't doing it - httpd is failing to start on
You could write an obfuscator. Maybe Acme::EyeDrop works?
See
http://domm.zsi.at/source_code/obfu/O.pm
for an obfuscated mod_perl handler.
A very simple thing to do is eg:
$yourcode=s/\s+/~/gs;
Than, in to be obfuscated module, do:
$_='package~Your::Code'.$yourcode;s/~/ /g;eval;
That's basically what I did in my mod_perl obfu.
This definitly isn't unbreakable, but (if you add some more
obfu-tricks and maybe do some encryption on the code to be evaled)
would require some knowledge to deparse.
I guess you started this thread on perlmonks?
http://www.perlmonks.org/index.pl?node_id=183932
If not, read it.
--
#!/usr/bin/perlhttp://domm.zsi.at
for(ref(bless[],just'another'perl'hacker)){s-:+-$-gprint$_.$/}
Re: Hiding perl code
Hi ( 02.07.22 10:15 -0400 ) Jon: At my former employer's, we built an Enterprise Management System out of mod_perl. He wants to distribute it to clients w/o risking theft of his code. Well, I'll save the intellectual property rant, but it's going to be very difficult to do. Perl is set up for sharing, not hiding. You might be able to use a crypto dependency to accomplish some of the same ends. You'd need a key pair to make this work. Take a low level variable and expect it's value to be held in an encrypted file. Encrypt the file with your private key and have the code decrypt it to operate. The public key can be contained in the code. So this file becomes a software 'dongle' of some type. It's not perfect, and certainly breakable [just rewrite the code with the crypto dependency], but may be applicable to your case. -- \js A thing is not necessarily true because a man dies for it.
[OT] Re: Hiding perl code
On Mon, 22 Jul 2002, Andreas J. Koenig wrote:
On Mon, 22 Jul 2002 13:10:25 +1000, Iain Truskett [EMAIL PROTECTED] said:
As far as I know, there's no good way to do it. It is Perl after all.
And with mod_perl things just get trickier.
Filter::decrypt does that. It's very hard to break as you compile a
self-made key statically into your perl. Filter::decrypt also disables
the debugger within that perl. Can also be done for mod_perl. The
encrypted modules look like this:
use Filter::decrypt ;
ÿ £j¨tBÓavð@¥£hK6' {'Þ^z'
[]
Of course, perl itself (or mod_perl) sees the cleartext, so a good
hacker will find a way to break it.
perl -MO=Deparse /path/to/encrypted/file(s)
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: [OT] Re: Hiding perl code
On Mon, 22 Jul 2002 10:17:21 -0500 (CDT), Dave Rolsky [EMAIL PROTECTED] said:
use Filter::decrypt ;
ÿ £j¨tBÃavð@¥£hK6' {'ÂÃ^zÂ'
[]
Of course, perl itself (or mod_perl) sees the cleartext, so a good
hacker will find a way to break it.
perl -MO=Deparse /path/to/encrypted/file(s)
Funny, that would be a nice test. Unfortunately I have only encrypted
files for an old perl and have never tried with a perl that is
Deparse-enabled. If anybody else is willing to test how well Dave's
suggestion works, please post your experience.
--
andreas
Static vs. DSO on Linux specifically
I've seen a lot of comments which seem to me to say that a static mod_perl is the only way to go. But Redhat ships it as a DSO. Now, on the one hand, I wouldn't just automatically assume that Redhat knew what they were doing. On the other hand, I've asked a couple local mod_perl junkies I know how static was better, and they didn't have any good answers for the Intel / Linux environment (though they definitely knew reasons for the Windows environment). (And I know a static setup would use somewhat less memory; but the last memory I bought for this server cost me $16.04 per 128MB, and it's connected to the net over only a 768k DSL line, so I'm not running *hundreds* of server processes; more like *tens*.) What I've found on the web so far makes claims strong enough that I feel my experience contradicts them adequately, and makes few actual *explanations*. So, specifically for the Linux environment, what are the downsides of running mod_perl as a DSO? (Pointers to the FM so I can R it would be fine.) -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: Static vs. DSO on Linux specifically
Hi!
On Mon, Jul 22, 2002 at 10:26:32AM -0500, David Dyer-Bennet wrote:
So, specifically for the Linux environment, what are the downsides of
running mod_perl as a DSO? (Pointers to the FM so I can R it would be
fine.)
Did you take a look at this:
http://perl.apache.org/docs/1.0/guide/install.html#Pros_and_Cons_of_Building_mod_perl_as_DSO
?
--
#!/usr/bin/perlhttp://domm.zsi.at
for(ref(bless[],just'another'perl'hacker)){s-:+-$-gprint$_.$/}
Re: Static vs. DSO on Linux specifically
On 22 Jul 2002, David Dyer-Bennet wrote: So, specifically for the Linux environment, what are the downsides of running mod_perl as a DSO? (Pointers to the FM so I can R it would be fine.) Segmentation faults, pure and simple. The Apache/mod_perl that ships with Redhat, and I assume other DSO Apache/mod_perl setups, is unstable. Here's one place I've seen this mentioned: http://masonhq.com/docs/faq/#why_am_i_getting_segmentation_fa -sam
Re: Static vs. DSO on Linux specifically
Hi David, On 22 Jul 2002, David Dyer-Bennet wrote: But Redhat ships it as a DSO. Debian also, but I think that is only for simplicity. It would be 'expensive' to produce static versions of apache with mod_perl, or with mod_php or both. On the other hand, I've asked a couple local mod_perl junkies I know how static was better, and they didn't have any good answers for the Intel / Linux environment (though they definitely knew reasons for the Windows environment). The reason for me was 'too many open file handles'. Every http daemon has a file handle for every DSO module, moreover a file handle for every log file. After sometime I started to have that error and found static building the best solution for my problem. IIRC, DSO is still marked as experimental in apache source. Last, but not least, conf files look better :) Ciao, Valerio Valerio Paolini, http://130.136.3.200/~paolini -- what is open-source about? Learn, and then give back
Re: Static vs. DSO on Linux specifically
On 22 Jul 2002 10:26:32 -0500, David Dyer-Bennet [EMAIL PROTECTED] said: DD I've seen a lot of comments which seem to me to say that a static DD mod_perl is the only way to go. I've been using mod_perl as DSO for more than one year (or even maybe two) without any problems on FreeBSD/Linux/Intel. My understanding is that there was some problems in the past and there are still some issues on some platforms but Linux/Intel platform is safe. DD But Redhat ships it as a DSO. DD Now, on the one hand, I wouldn't just automatically assume that Redhat DD knew what they were doing. I would not trust RedHat to much to do right thing with Perl. They are know to produce broken mod_perl packages in the past for example. DD [..snip..] -- Ilya Martynov (http://martynov.org/)
RE: Static vs. DSO on Linux specifically
Of course this is an old conversation, but we use mod_perl as a DSO here extensively with no problems. We have servers that have uptimes of almost 1 year (306 days as of today) and were taken down because the servers were moved to a new server room and not because of a problem with the DSO. And we get several thousand hits a day during the school year. It has been my experience that DSO vs. Static is not the issue it once was. Joe -Original Message- From: David Dyer-Bennet [mailto:[EMAIL PROTECTED]] Sent: Monday, July 22, 2002 10:27 AM To: [EMAIL PROTECTED] Subject: Static vs. DSO on Linux specifically I've seen a lot of comments which seem to me to say that a static mod_perl is the only way to go. But Redhat ships it as a DSO. Now, on the one hand, I wouldn't just automatically assume that Redhat knew what they were doing. On the other hand, I've asked a couple local mod_perl junkies I know how static was better, and they didn't have any good answers for the Intel / Linux environment (though they definitely knew reasons for the Windows environment). (And I know a static setup would use somewhat less memory; but the last memory I bought for this server cost me $16.04 per 128MB, and it's connected to the net over only a 768k DSL line, so I'm not running *hundreds* of server processes; more like *tens*.) What I've found on the web so far makes claims strong enough that I feel my experience contradicts them adequately, and makes few actual *explanations*. So, specifically for the Linux environment, what are the downsides of running mod_perl as a DSO? (Pointers to the FM so I can R it would be fine.) -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: Static vs. DSO on Linux specifically
Thomas Klausner [EMAIL PROTECTED] writes: Hi! On Mon, Jul 22, 2002 at 10:26:32AM -0500, David Dyer-Bennet wrote: So, specifically for the Linux environment, what are the downsides of running mod_perl as a DSO? (Pointers to the FM so I can R it would be fine.) Did you take a look at this: http://perl.apache.org/docs/1.0/guide/install.html#Pros_and_Cons_of_Building_mod_perl_as_DSO ? Yes, and it seemed quite inconclusive, whereas some of the discussion I have heard from people makes it sound *important*. And the guide doesn't mention the two issues that people have mentioned on this list in response to my post (file handles and segfaults). -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
RE: Mail::Sender modperl.
Richard,
I also use MIME::Lite (on Win2000) with mod_perl. Found it to be quite reliable and
it supports attachments and receipts like so:
if($aReceipt ne '') { # If return receipt requested.
$msg-add(Disposition-Notification-To= $aApobj-getEmail_Address);
}
Chuck
-Original Message-
From: Richard Clarke [mailto:[EMAIL PROTECTED]]
Sent: Saturday, July 20, 2002 6:28 AM
To: [EMAIL PROTECTED]
Subject: Mail::Sender modperl.
List,
Have any of you had any problems using Mail::Sender from within
mod_perl. My script seems to just sit there waiting for $sender-Open to
do anything. I will email the author also but imagined he *might* not be
familiar with mod_perl so won't be able to offer any suggestions.
Anyone? I looked through the archives but saw no reference to a problem
like this. Some people indicated much success with Mail::Sender (not so
for me however!).
Second, the recommended solution for sending mails is to instead put
them on a queue for an external daemon to handle. My question is, is
there a standard implementation people use when doing this. Is the KISS
theory invoked and the outoing mail simply written to some plain text
spool file or do people use something more involved like writing the
to,cc,from,subject,body test to a database and storing any temporary
files (attachment) in a directory for later encoding?
Ric
p.s. here is an excerpt from my apache log indicating precisely what happens
220 mail.likewhoa.com ESMTP Postfix
421 Error: timeout exceeded
ehlo localhost
mail from: [EMAIL PROTECTED]
rcpt to: [EMAIL PROTECTED]
data
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
X-Mailer: Perl script null
using Mail::Sender 0.7.14.1 by Jenda Krynicky
running on localhost (127.0.0.1)
under account root
Date: Sat, 20 Jul 2002 13:18:12 -
Message-ID: [EMAIL PROTECTED]
Subject: msg msg msg
close sender
.
quit
done
The request took 305.710375070572 seconds
Re: Apache-print Timed Out
On 7/21/02 8:19 AM, Ask Bjoern Hansen [EMAIL PROTECTED] claimed: You didn't tell which version of MSIE they use; but if it's not recent it could be some CSS that makes the browser act up[1]. V.5, I think. It doesn't happen on OS X, though, only OS 9. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
[DIGEST] mod_perl digest 2002/07/15
-- mod_perl digest July 15, 2002 - July 21, 2002 -- Recent happenings in the mod_perl world... Greetings from the O'Reilly Open Source Convention Features o mod_perl status o module announcements o module rfcs o mod_perler wanted o mailing list highlights o links mod_perl status o mod_perl - stable: 1.27 (released June 1, 2002) [1] - development: 1.27_01-dev [2] o Apache - stable: 1.3.26 (released June 18, 2002) [3] - development: 1.3.27-dev [4] o mod_perl 2.0 - beta: 1.99_04 (released June 21, 2002) [5] - development: (cvs only) [6] o Apache 2.0 - stable: 2.0.39 (released June 17, 2002) [7] o Perl - stable: 5.6.1 (released April 9, 2001) [8] - development: 5.8.0-RC3 [9] module announcements o Apache::Session::Serialize::YAML 0.01 - allows Apache::Session to use YAML for session serialization [10] o Petal 0.1 - Perl Template Attribute Language [11] module rfcs o Agenda - website framework [12] available mod_perlers o Apache/Perl/Java devloper in San Dieg, CA [13] mailing list highlights o TIPool / multiple database connections and a discussion of sharing data between threads - [14] links o The Apache/Perl Integration Project [15] o mod_perl documentation [16] o Apache modules on CPAN [17] o mod_perl homepage [18] o mod_perl news and advocacy [19] o mod_perl list archives - modperl@ [20] [21] - dev@ [22] [23] - docs-dev@ [24] - advocacy@ [25] happy mod_perling... --James [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://cvs.apache.org/snapshots/modperl/ [3] http://www.apache.org/dist/httpd/ [4] http://cvs.apache.org/snapshots/apache-1.3/ [5] http://perl.apache.org/dist/mod_perl-1.99_04.tar.gz [6] http://cvs.apache.org/snapshots/modperl-2.0/ [7] http://www.apache.org/dist/httpd/ [8] http://www.cpan.org/src/stable.tar.gz [9] http://www.cpan.org/src/devel.tar.gz [10] http://mathforum.org/epigone/modperl/glahtrapar [11] http://mathforum.org/epigone/modperl/khaxloasnung [12] http://mathforum.org/epigone/modperl/jeeblurceu [13] http://mathforum.org/epigone/modperl/zoxcoclar [14] http://mathforum.org/epigone/modperl/ghixfumskerl [15] http://perl.apache.org/ [16] http://perl.apache.org/docs/ [17] http://www.cpan.org/modules/by-module/Apache/ [18] http://www.modperl.com/ [19] http://www.take23.org/ [20] http://mathforum.org/epigone/modperl/ [21] http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2 [22] http://marc.theaimsgroup.com/?l=apache-modperl-devr=1w=2 [23] http://www.mail-archive.com/dev%40perl.apache.org/ [24] http://perl.apache.org/mail/docs-dev/ [25] http://www.mail-archive.com/advocacy@perl.apache.org/
.bml files not executing in apache
Hi All,I am setting up a livejournal server and have installed modperl on a windows xp machine. Livejournal uses bradfitz bml (better markup language) to control its look. On my system however, the .bml files do not execute. When I access them I get source only. I'm told BML is a standard part of modperl now, but I suspect there is not something set up correctly in my httpd.conf file to make it execute properly bml.pm. I created a minimal httpd.conf file based on the livejournal manual which I have attached my httpd file at the end of this message. Can anyone help me?Thanks in advanceRandyHttpd.conf contains:ServerType standaloneServerRoot "c:\apache"PidFile logs/httpd.pidScoreBoardFile logs/apache_runtime_statusTimeout 30KeepAlive OffMinSpareServers 5MaxSpareServers 40#StartServers 10MaxClients 20MaxRequestsPerChild 500LoadFile "C:/openssl/bin/libeay32.dll"LoadFile "C:/openssl/bin/ssleay32.dll"LoadModule ssl_module modules/mod_ssl.soLoadFile "C:/Apache/modules/php4ts.dll"LoadModule php4_module modules/php4apache.dllLoadFile "C:/Perl/bin/perl56.dll"LoadModule perl_module modules/mod_perl.soClearModuleList#AddModule mod_env.cAddModule mod_mime.c#AddModule mod_negotiation.c#AddModule mod_status.c#AddModule mod_info.c#AddModule mod_include.cAddModule mod_autoindex.cAddModule mod_dir.c#AddModule mod_perl.cAddModule mod_so.cAddModule mod_setenvif.cAddModule mod_php4.cAddModule mod_perl.cAddModule mod_ssl.cPort 80#User lj#Group ljSendBufferSize 131072ServerName www.thefreemachine.ccDocumentRoot "c:\livejournal\htdocs"PerlSetEnv LJHOME c:\livejournalPerlRequire c:\livejournal\cgi-bin\modperl.pl
Re: .bml files not executing in apache
On Mon, 22 Jul 2002, randy reed wrote: Hi All, I am setting up a livejournal server and have installed modperl on a windows xp machine. Livejournal uses bradfitz bml (better markup language) to control its look. On my system however, the .bml files do not execute. When I access them I get source only. I'm told BML is a standard part of modperl now, but I suspect there is not something set up correctly in my httpd.conf file to make it execute properly bml.pm. I created a minimal httpd.conf file based on the livejournal manual which I have attached my httpd file at the end of this message. Can anyone help me? Thanks in advance Randy [ ... ] bml isn't part of a standard mod_perl distribution. From the sources at http://www.bradfitz.com/bml/, it's apparent one has to do some configuration to tell Apache what action to take with bml files. Try getting that working under standard cgi, and then from there try adapting it to mod_perl, perhaps under Apache::Registry. However, this may be difficult, as the bml handler, bmlp.pl, doesn't compile under 'use strict;', which is generally good practice to use for registry scripts. -- best regards, randy kobes
Re: Unable to build Apache::ePerl
Thanks to everyone who responded publicly and privately. I'm close to getting Apache::ePerl built, but I still have the problem with the C compiler error. Do I need to downgrade my version of gcc to get Apache::ePerl (from eperl-2.2.14 or eperl-2.2.13) made and installed? Output from gcc -v is gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-110). Here's the compiler error I get when attempting to run make on ePerl: cd mod make make[1]: Entering directory `/home/gregg/eperl-2.2.14/mod' make[2]: Entering directory `/home/gregg/eperl-2.2.14/mod/Parse' cp ePerl.pm ../blib/lib/Parse/ePerl.pm AutoSplitting ../blib/lib/Parse/ePerl.pm (../blib/lib/auto/Parse/ePerl) /usr/local/bin/perl -I/usr/local/lib/perl5/5.6.1/i686-linux -I/usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/5.6.1/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.6.1/ExtUtils/typemap ePerl.xs ePerl.xsc mv ePerl.xsc ePerl.c cc -c -I/home/gregg/eperl-2.2.14 -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\2.0214\ -DXS_VERSION=\2.0214\ -fpic -I/usr/local/lib/perl5/5.6.1/i686-linux/CORE ePerl.c In file included from ePerl.xs:49: /home/gregg/eperl-2.2.14/eperl_proto.h:84: parse error before `__extension__' /home/gregg/eperl-2.2.14/eperl_proto.h:84: parse error before `n' /home/gregg/eperl-2.2.14/eperl_proto.h:84: parse error before `if' /home/gregg/eperl-2.2.14/eperl_proto.h:84: conflicting types for `__retval' /home/gregg/eperl-2.2.14/eperl_proto.h:84: previous declaration of `__retval' /home/gregg/eperl-2.2.14/eperl_proto.h:84: `__len' undeclared here (not in a function) /home/gregg/eperl-2.2.14/eperl_proto.h:84: warning: initialization makes integer from pointer without a cast /home/gregg/eperl-2.2.14/eperl_proto.h:84: initializer element is not constant /home/gregg/eperl-2.2.14/eperl_proto.h:84: warning: data definition has no type or storage class /home/gregg/eperl-2.2.14/eperl_proto.h:84: parse error before `if' /home/gregg/eperl-2.2.14/eperl_proto.h:84: redefinition of `__retval' /home/gregg/eperl-2.2.14/eperl_proto.h:84: `__retval' previously defined here /home/gregg/eperl-2.2.14/eperl_proto.h:84: parse error before `char' /home/gregg/eperl-2.2.14/eperl_proto.h:84: warning: data definition has no type or storage class /home/gregg/eperl-2.2.14/eperl_proto.h:84: warning: data definition has no type or storage class /home/gregg/eperl-2.2.14/eperl_proto.h:84: parse error before `}' make[2]: *** [ePerl.o] Error 1 make[2]: Leaving directory `/home/gregg/eperl-2.2.14/mod/Parse' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/home/gregg/eperl-2.2.14/mod' make: *** [all] Error 2 Thanks for help any of you can provide, Gregg Casillo
Re: Hiding perl code
Jon, I've been doing some thinking along these lines (for website security, not for releasing code). I don't have a solution, but below are some thoughts I've had. I would love to hear from anyone who knows solutions for any of the points below. Most of the thoughts below are based on encryption, as I don't believe that obfuscating or compiling offer any real security for an attacker who is determined. For Apache::Registry (or Apache::PerlRun) scripts, it should be fairly trivial to write an Apache::RegistryEncrypt, based on Apache::RegistryNG, that would first decrypt a source file during compile using a public key stored in a (presumably) safe location before turning it into a module. The secret key could be stored on a different (development) server and not be accessible, which would give you fairly good security, both for reading and writing. Unfortunately, this would not protect modules (particularly application modules) which are use'd from these scripts. For modules, it might be possible to write a module which would first decrypt a file before using it (would something using the same type of method as ex::lib::zip* work?). Modules could then be preloaded using PerlModule from the Apache configuration or use lines from a startup.pl file. However, I imagine it might be difficult to decide which modules *have* to be encrypted - if all modules have to be encrypted, that would affect even standard modules, but if it is selectable, there would have to be a way of keeping an attacker from simply placing a module earlier in the INC path. Maybe something like everything with the FOOBAR:: prefix has to be encrypted? The other benefit of this is that the same solution would also work for encrypting true mod_perl handlers, not just scripts. I believe this would be preferable to using a source filter, as a source filter would only protect reading, not writing. Since a source filter operates on everything after the use Filter::Whatever; line, an attacker could simply place code above that line, or replace the file completely and negate any benefit from using it. Besides that, it might be difficult to access a public key from a source filter in a secure manner. For website security, the other solution I considered was to use Apache::RegistryBB or something homebrew which wouldn't check the modification time of a script after the initial compile and use, then simply unmount the filesystem after Apache startup. Of course, like the above solution, this only protects the on-disk copy, the code would still be accessible in memory if debugging was available, etc. Other than that, this just seems like a clunky solution, and not very good if the filesystem has to be manually mounted to restart the webserver, but the admin isn't available :-) Thanks, Nathan Byrd * http://search.cpan.org/search?mode=modulequery=ex%3A%3Alib%3A%3Azip On Sun, 2002-07-21 at 21:58, Jonathon M. Robison wrote: Anyone know offhand a good way to hide your perl code when using mod_perl? Acme::Bleach isn't doing it - httpd is failing to start on initial test, and then on second test I find that httpd.conf suddenly got a 'use Acme::Bleach' inserted at line 1 and the whole thing is bleached. Perhaps perl2exe? --Jon R
