need custom script done
 

need custom script done

icq me 122295837

bumpidy bump bump :)

What language(s) and if you need db support might help get the right people to contact you. :thumbsup

cgi/perl or

php --> MySQL database

Now you're talking!

Contact James - he's written some custom stuff for us. He's fast, very reasonable and his stuff works great. He's [email protected]

thanks just sent an email to him :)

I am ok if you want it to be php+MySQL stuff.
I hate perl and personally think that ti's a security risk to put a perl stuff on a web server.

ICQ: 171216535
mail: ice [ at ] icefire.org

bump

Depending on how large the script is I may have time as soon as tomorrow. I have to start a new script Monday but if I can get it done before that I would be more than happy to do it.

do u have icq ?

mine is icq 122295837

See what happens when I post at 4am? Got his addy wrong. It's [email protected]

:thumbsup

:1orglaugh :1orglaugh :1orglaugh :1orglaugh :321GFY


Umm what planet are you from exactly?
Perl applications have been used by system administrators for a lot longer than you have been out of diapers.

:1orglaugh :1orglaugh :1orglaugh :1orglaugh

A search of Bugtraq at SecurityFocus reveals:

451 results matching "Php"
173 results matching "Perl"

Keep in mind Perl has been around considerably longer than perl as well.

Running PHP is leaps and bounds more of a security risk than properly coded Perl could ever be.

I think maybe his perl-is-bad experience must come from exploiting poorly coded canned scripts or something.

That's the only reason I think someone could come to that conclusion.

PHP used to have remote root exploits like every 3 months. Now they are down to every 6 months or so.. :)

Don't get me wrong, PHP is great for what it is & for quickly developing certain applications. Great for templating....
BUT, their security fixes suggest that there is greater risk in using PHP over Perl no matter how you slice it.

Hi,

looking forward to email - [email protected]

:)

Well, the reasons are quite complex but here comes a simple resume

1) Perl executes directly on the system --> any security hole in your script leads to direct command execution on the system with the privileges of your web server.
2) PHP is a module, so it relies on apache (unless you are stupid enought to run it as CGI), then any security hole becomes harder to explot (still possible).
3) You have not the security structure php has with it's config level (safe_mode, include_dir etc..). If you use perl you access to all the server directory unless you use several extra modules to protect the perl environment and pseudochroot it.
4) Perl uses to be slower when it comes to web database driven apps. The perl interpreter itself runs faster that PHP, but it takes some time to load it (more memory etc...). PHP is always loaded on your apache if you use it as module. If you have a 200 lines php app it will go faster that with perl, but if you have 20.000 lines application you should choose delphi or C instead of php (perl will do the work but will be still slow).

Don't take me wrong, perl is great, but it was thinked as a system administration helper scripting language, not as a web programming language. I use perl to automate tasks on my boxes, but I never put it on the web.

1 & 2. ummm unless there is perl code to directly run a system command on submitted data, no perl does not execute any system commands.

3. I can just as easily use php to access any directory on the server where the permissions allow it the exact same as perl.

4. a perl script written correctly can be loaded as mod_perl in apache and does not need to be loaded each time it runs, thus being faster. No idea if it will or will not be faster than a similar php application, just pointing out the flaw in your thinking.


sometimes it is far better to keep your mouth closed and be thought a fool, than to open it and remove all doubt.

1) Perl executes directly on the system --> any security hole in your script leads to direct command execution on the system with
the privileges of your web server.


You can use a CGIWrapper to prevent perl from doing system calls if that's something you need to worry about. Also keep in mind in most cases they would be ran as the apache user. And the same thing goes for system calls in PHP I believe.

Servers should be kept up to date security wise anyway.



2) PHP is a module, so it relies on apache (unless you are stupid enought to run it as CGI), then any security hole becomes harder to explot (still possible).


No, PHP can be compiled and installed as an apache module. So can perl.


3) You have not the security structure php has with it's config level (safe_mode, include_dir etc..). If you use perl you access to all the server directory unless you use several extra modules to protect the perl environment and pseudochroot it.


Heh or unless you write cleaner/safer code.

But I don't know enough about PHP's 'config levels' to argue about that one.


4) Perl uses to be slower when it comes to web database driven apps. The perl interpreter itself runs faster that PHP, but it takes some time to load it (more memory etc...). PHP is always loaded on your apache if you use it as module. If you have a 200 lines php app it will go faster that with perl, but if you have 20.000 lines application you should choose delphi or C instead of php (perl will do the work but will be still slow).


mod_perl used correctly will smoke PHP I believe.
But this isn't a Perl VS PHP _performance_ thread... it's based on you comments that perl is more of a security risk than perl.

And like I said, historically, over a much shorter period of time, PHP has claimed FAR MORE remote root compromises than Perl has.