Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: perl2exe - no more secrets

by gmax (Abbot)
on Feb 23, 2003 at 21:37 UTC ( [id://237952]=note: print w/replies, xml ) Need Help??


in reply to perl2exe - no more secrets

An interesting quote from the author of perl2exe analysis.
See the whole paper here .
(...)
I started to wonder why people use these Perl compilers, and then it hit me. They're obviously not used for security, since they provide no security. They're obviously not used for licence enforcement, since Bad Guys aren't going to stop to think about licences anyway, and Good Guys won't rip you off.

They're actually used out of shame; most of the code I've seen packaged up with these things is of amazingly poor quality, and I can understand why you wouldn't want people to look at that kind of code if you're making a commercial product out of it. People don't want to expose the fact that they're selling really quite bad programs for really too much money. If these programmers had a bit more pride in their Perl abilities and a little bit more honesty with their customers, the need for these sort of "compilers" would go away, and the problem would be solved.
(I underlined it.)

Lessons learned
Learn how to program properly, and forget about perl2exe!
 _  _ _  _  
(_|| | |(_|><
 _|   

Replies are listed 'Best First'.
Re: Re: perl2exe - no more secrets
by Marza (Vicar) on Feb 24, 2003 at 08:09 UTC

    Hmm that seems to be a rather broad statement. I use perlapp since the company bought it for me. I don't create executables to hide code. My code may not be a merlyns level but I don't think it is rubish either.

    The times when I have deploy executables it is not to hide source code(you can find the source with the executable in our downloads area); it is for small utils on machines that don't need Perl installed. Especially since the people that use these machines think Perl is found on ear rings and necklaces.

    As to security issues? Security is a state of mind. Bad practices happen even if a script is not compiled.

    For example, I have found scripts that had passwords embeded in them.

      For example, I have found scripts that had passwords embeded in them.

      Im always amused when someone says something like this. My response is: so what?!

      Embedding passwords in a script is hardly automatic cause to be shot. Sure its not ideal, and there are situations where doing so would be virtually if not actually criminally negligent, but equally there are many scenarios where embedding passwords into the script itself makes quite a lot of sense. Or at bare minimum, where it does not not makes sense.

      Consider If I put my password in a ini file in the same directory as the script, is it really any more secure than the same password in the perl script that will use it? No it isn't. The basic fact is that the password will only be as secure as the OS restrictions make it. If the password is in the script and the script is readable by everyone, then you have a problem. The same problem with the ini file applies though. And you never hear anybody protesting "yeah but the password is in the inifile".

      Now before anybody says "putting a password in a file of any sort is a bad plan," I'll agree: Yup you're right. So how do you run cron jobs that need passwords? You put the password in a file? Ahah!

      Anyway, just one of my pet peeves. :-)


      ---
      demerphq

      <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...

      • Update:  
      Just in case anybody thinks that I think that it is sane to put sensitive passwords in a perl2exe script, I dont. My point is just that putting a password into a script isn't defacto a security hole. Pretty well its never ideal to do so, but it isn't necessarily a security matter.


        That is a pretty broad cast you've tossed there. ;-)

        It depends on the job and the id involved.

        If it was a script that only root would use, then there is not really a problem as long as nobody else gets access to the script.

        If it is a lowlevel user id, you can debate it.

        If it is a script that has root and its plaintext password embeded which everybody is going to use, then you have a gigantic hole(This was my situation).

        Now as to embeded passwords being a security risk; a real life example.

        Progammer A, thinks like you do. Programmer B hates programmer A and wants to see him fired. Progammer B finds A's password. Programmer B starts using A's account to delete things, print porn on the vice-presidents Assistents printer, etc....

        We figured it out but not until after programmer A was put through a suspension(ie the pornography and the sexual harrasment policies).

Re: Re: perl2exe - no more secrets
by Anonymous Monk on Feb 24, 2003 at 01:54 UTC
    Learn how to program properly, and forget about perl2exe!

    As long as this is the attitude of the Perl community, Perl will never be used for enterprise application development. I see frequent discussions asking for examples of commercial apps, large apps, and graphical apps. Granted, there are a couple examples out there but they are mostly low-profile and by most standards unsuccessful.

    What Perl needs to take it to the next level is a good native compiler. I understand why people are against this, but I believe through the increased use and associated publicity of Perl it would in fact help the oss movement more than it would hurt it.

    There are plenty of good reasons for native compilation, pretending that the only reason is to hide low-quality code is very ignorant. I'm still not sure this was your point though, so I apologize if I misinterpreted.

    Then again, you could argue Perl has found its place already and shouldn't try to expand beyond its role. I personally think world domination is a much better goal ;-).

      While you are right that many enterprise users want a perl compiler, perl2exe is not a compiler. What it gives you is an executable that contains the perl binary, required libraries, and your script. It allows you to create standalone binaries, but it does not compile your perl to a native application, it simply bundles it with an appropriate perl interpreter.

      Enterprise development? It sounds more like you're talking about packaged commercial applications. Enterprise development usually means something built in-house that is specific to a business. These days it often means putting the company's business on the web, which would not involve a compiler.

      I agree that the inability to effectively compile Perl works against it being used to build packaged commercial software, but that's a fairly unusual thing to choose Perl for. That realm seems pretty well locked up by C++. Perl is more at home on the server side, where this sort of thing is not an issue.

        Sorry, wrong buzzword. You got my point though :)

        As for using perl for packaged commercial software, I mostly agree with your point. Personally I wouldn't use perl for such a project but there are those who definately would like to. I think it also applies to the server-side. Sadly, not every company wants to give the source out to every product they sell. This leads them to other languages. Is this good or bad? Hard to say, but people shouldn't be surprised when some companies don't consider perl and option because of it.

      A very good explanation why a "good native compiler" will not be better than the Perl.pl to Perl.exe utilities we already have, can be found in " Why Not Translate Perl to C?".

      CountZero

      "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

        A very good explanation why a "good native compiler" will not be better than the Perl.pl to Perl.exe utilities we already have, can be found in " Why Not Translate Perl to C?".
        Except that that explanation is baloney. People have been compiling dynamic languages (such as LISP) for decades. Yeah, it's hard. But it does make programs much faster.

        Yeah, I read that one a while back and I completely disagree with it. It sounds kind of like this to me:

        the Perl vm is pretty good for a vm and it might take a little effort to write a better compiler, so perl's perfect again, so yeah, move along. what do you mean that doesn't make any sense? well, you obviously don't know what you're talking about. See this function? it's fast in perl. If I poorly write a c-equivalent, it's slow. So why don't I write it well? because perl is good. Perl rox0rs.

        The end.

        It's very possibly to write a native compiler for Perl that would produce faster, more efficient code. Nobody seems to want to do it though, probably because they don't want to deal with the negative response from the community. So instead they focus on the next-gen scripting languages.

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Re: perl2exe - no more secrets
by zakzebrowski (Curate) on Feb 24, 2003 at 11:50 UTC
    You're simplifying the argument a bit too much for my taste... What happens when you can't install perl on the target system(s) you wish to run the software on?

    ----
    Zak
    Pluralitas non est ponenda sine neccesitate - mysql's philosphy
      Then you use PAR, as merlyn already pointed out.

      Makeshifts last the longest.

        The PAR solution available is no argument for NOT using PerApp or perl2exe if it is just about being able to redistribute Perl software without Perl installation.

        That's just another way. Also (slightly) more complex if you are used to download ActiveState Perl Install-executables and use PPM for module installation.

        Q: Why did the Perlmonk cross the road?
        A: He wanted to escape the match.

        i tried (hard) to install the PAR suite in my ActiveState Perl environment, with no luck. perl2exe works out of box, and allows me to deploy standalone scripts (while i would not be allowed to install perl). deploy, run, remove... i'd gladly switch to PAR, but it never worked for me.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://237952]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (4)
As of 2024-03-19 05:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found