http://www.perlmonks.org?node_id=238053


in reply to Re: perl2exe - no more secrets
in thread perl2exe - no more secrets

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.

Replies are listed 'Best First'.
Re: Re: Re: perl2exe - no more secrets
by demerphq (Chancellor) on Apr 22, 2003 at 15:41 UTC

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