On Sun, Mar 02, 2003 at 10:04:44AM +0100, luc willems wrote: > 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.
No, it does not. I used the 'anonymous file' feature provided by
IO::File->new_tmpfile, so it is deleted immediately after creasion,
instead of 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 .
See above. I don't know if it still occupy disk space or not, though --
can you experiment a bit and see if it's the case? If yes, I'll be
happy to take your patch to enable a PerlIO-based filter approach on
Perl 5.8 with PerlIO built.
Also, there is currently no way I know of to load shared libaries from
memory without writing them to disk. I'll be glad to learn otherwise.
> 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 ?
A system that places its core runtime at a remote host, and depends on
remote connection and signed code to run, is a lot closer to
bullet-proof. :-)
Also, if the user is required to enter (or set in environment?) the
'decrypt' key, then it's not strictly security-by-obscurity -- people
without the key, even if they obtain the encrypted PAR, is unlikely to
find out the original source code, given a strong enough cipher.
> 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.
This is a *VERY* good suggestion that I hope I can think of earlier!
However as outlined in the presentation, I believe it is best to split
the metadata into three files, none of which is mandatory:
MANIFEST Contains a list of packed files, with optional comments.
META.yml Contains the metadata of this package.
SIGNATURE Contains a signed list of packed files and their checksums.
The runtime semantics, as you suggested, will be specified in META.yml
below (if 'key' is unspecified, then it will probably require user input):
--- #YAML:1.0
build_requires: {}
conflicts: {}
dist_name: a.out
distribution_type: par
dynamic_config: 0
generated_by: 'Perl Packager version 0.03'
license: unknown
par:
cipher: Crypt::Rijndael
cleartemp: 1
decrypt: 1
key: abacadabra
signature: 1
That way any arbitary configurations can be added, and overriden with
environment variables like $ENV{PAR_DECRYPT}. Is that good enough for
you?
I'll probably stick with YAML instead of XML on this one, since the
latter is not easily line-parsable, and Module::Build / Module::Install
/ FreePAN will probably make use of META.yml too.
> 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.
Very very true. If anybody on the list have prior experience with JAR,
I'd like to have some hints about what sort of metadata they provide
within a JAR file, so we can translate them into equivalent META.yml
configurations...
> 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.
Yes, a decompiler is easy to come by, in particular in Java's case.
'pp', or App::Packer, can make use of a input-filter mechanism.
For example, somebody has mentioned that Pod::Stripper is very suited
to apply to prerequisite modules before packing them.
I can imagine people putting B::Deparse, B::Bytecode, Acme::Bleach,
My::Varname::Discordian, or Filter::Golf in that place, which will
(to a degree) obfuscate things in a clean, customizable manner, unlike
the other commercial offerings.
> Don't get me wrong , i like the fact off OPEN source but the real live
> out there isn't always perfect.
Nah, people have different needs. Tools like perl or PAR should be
humble, instead of trying to enforce any ideology upon its users...
Thanks,
/Autrijus/
pgp00000.pgp
Description: PGP signature
