On Saturday 01 March 2003 16:17, Autrijus Tang wrote:
>
> It is surely quite inappropriate for that.  If you can trick the
> resulting application to set $ENV{PAR_CLEARTEMP}, then you'll get
> the desired (pre-0.60) behaviour.
>
> Actually I wrote this in the POD:
>

Hello again ,

I had a look into the module code and it' seems that it still creates a file in tmp 
using the PAR_CLEARTMP setting but it erases it after execution.
My point is that i don't want this file in the life time off the application.
I' want to use the PAR file in a Apache - Mod Perl environment where the livetime of 1 
http process can be very long. 
Until it dies , these file are left there .  

I took the comments of the slides and played a little bit with PAR.pm , and came to 
following solution with no tmp files hanging around
in the unpar subroutine :

    ......
   return $member if $member_only;

   if ($ENV{PAR_NOTEMP}) {
     my $code = read_file($filename);
     open my $fh,'<',\($code);  #as mentioned in the slides of Tang and perldoc -f 
require
     return $fh;
   }  else {
     my ($fh, $is_new) = _tmpfile($member->crc32String . ".pm");
     die "Bad Things Happened..." unless $fh;
     if ($is_new) {
         $member->extractToFileHandle($fh);
         seek ($fh, 0, 0);
     }
    return $fh;
  }
}


This will not create a file into tmp if PAR_NOTEMP is set.

This is a quick hack , and only works with PERL 5.8.0 and  probebly has some 
disadvantage but  i like it because it doesn't leave any thing behind.
Further , this can lead to a interface to "encrypting" the content of the PAR file 
and do the decrypting in memory .This is security by obscurity like it is mentioned 
in the perlcompile man pages but which system is 100% bullet proof ?

Maybe we can but this things in a MANIFEST file. Things like filename, filesize ,md5 
sum and working behaviour can
be put in the manifest file by the pp utility and PAR will use
this as a configuration, possible to override with some kind of enviroment variable.

I think this is a part where PAR can play a role , same as java has his class and jar 
file , perl needs something that can handle the functionality of a JAR file
(what we know have with PAR) and a way to "hide" de source code for any curious 
customer.
I see this all the time in my profesional live that people like perl but don't use it 
because "everybody" can copy my code.
So i have to use something else like C,C++ or JAVA because it compiles the code and 
nobody can see it.
We all know this is not always true but its hard to fight a myth.

Don't get me wrong , i like the fact off OPEN source but the real live out there isn't 
always perfect.


        greetings,
        luc


Reply via email to