On Wed, 6 Jan 2010, MJ Ray wrote:
Thomas Krichel <kric...@openlib.org> wrote:
Joe Hourcle writes
ps. yes, I could've used this response as an opportunity to bash
PHP ... and I didn't, because they might be learning PHP to
migrate it to something else.
controversial ;-)
what's the problem(s) with PHP?
Oh please don't nuke the list from orbit like that! I hope that
this is a balanced enough reply to keep everyone happy:
Our experience is that PHP hosting environments vary much more, most
PHP code is a mess (PHP-based software was part of 35% of the
U.S. government's National Vulnerability Database in 2008 -
http://www.coelho.net/php_cve.html) and few things (code and hosting)
move between the different major versions smoothly. It's a "personal
home page" tool which has grown massively, for better or worse.
BUT! Even after all that, software.coop still supports some PHP
applications because they can work well and be very useful, though
we're under no illusions about PHP's warts.
I can sum it up in one sentance:
PHP makes it *very* easy to write insecure programs.
Of the security incidents in our department (the ones where men with guns
come and take your hard drive and/or whole server away for an
'investigaton'), PHP has been responsible for the majority of the
incidents.
Part of it is the perceived simplicity -- look at how easy it is to add
some extra functionality to your website! You don't even need to
understand good programming practices! Anyone can do it!
(to be fair -- Perl used to be the software that fell into this niche 10
years ago, but I blame Matt's Script Archive more than the language
itself, as Perl isn't specifically for web site automation)
... and they never get their code reviewed by one of the professional
programmers in our department, it goes live, and then, a year or so later,
someone shows up to take our server because the security monitoring showed
that it looks like someone managed to pull our password file off the
system. (never mind that (1) there's a shadow file, so /etc/passwd has no
passwords in it, and (2) even if they got the password file, it only has
the application users (none of whom have login privs) because it's macosx)
Then you waste a week of your time trying to convince the security gestapo
that yes, there was a security vulnerability, and there was an incident,
but nothing confidential was actually lost ... and then we get everyone
who had stuff on the server bitching us out because they can't get to
their stuff, and they had some time-sensitive information to get out, or
whatever, and we're trying to jump through security's hoops for a week or
two while our other projects get further and further behind.
...
Now, if they actually manage to *upload* a file to your system ... then
expect to rebuild your whole machine from the ground up.
so um ... if you're going to use PHP ... if you're on apache, look into
suPHP. Consider making your website served from a read-only file system,
and look online for other tips on hardening your server.
-Joe
oh, and I also really disike having to tye all of my stuff to one
database. I know mysqli makes it better, but the original mysql stuff
still taints my perception of PHP.
I also have a dislike of ColdFusion servers, but that stems from the 'unix
registry' crap they used (still use?) back when they were still Allaire,
and I had a few times when the system choked and I had to rebuild all
settings from memory the first time, and from printouts of the server
configuration the next few times. And then there was the time at a
previous job when we upgraded the server and they pushed in changes that
made the service crash every night at about 2am ... so I'd get a call
every night to restart the thing ... until I finally wrote a watchdog
script which by the time I got fired, was restarting the service 5-8 times
per night ... but I actually *liked* coldfusion as a developer.
...
and so long as we're mentioning PHP, and this is code4lib -- anyone
personally know the developer of refbase? I tried emailing him a few
months back offering patches to get rid of all of the 'deprecated'
warnings when running under php5.
