RE: Mail::Sender modperl.

2002-07-22 Thread Joe Breeden

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

2002-07-22 Thread wsheldah



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

2002-07-22 Thread lembark



-- [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

2002-07-22 Thread 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.

--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

2002-07-22 Thread Andy Lester

 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

2002-07-22 Thread Thomas Klausner

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

2002-07-22 Thread John Saylor

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

2002-07-22 Thread Dave Rolsky

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

2002-07-22 Thread Andreas J. Koenig

 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

2002-07-22 Thread David Dyer-Bennet

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

2002-07-22 Thread Thomas Klausner

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

2002-07-22 Thread Sam Tregar

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

2002-07-22 Thread Valerio_Valdez Paolini


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

2002-07-22 Thread Ilya Martynov

 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

2002-07-22 Thread Joe Breeden

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

2002-07-22 Thread David Dyer-Bennet

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.

2002-07-22 Thread Goehring, Chuck Mr., RCI - San Diego

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

2002-07-22 Thread David Wheeler

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

2002-07-22 Thread jgsmith

--

  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

2002-07-22 Thread randy reed



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

2002-07-22 Thread Randy Kobes

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

2002-07-22 Thread Gregg Casillo

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

2002-07-22 Thread Nathan Byrd

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