PHP 5.2.2 and 4.4.7 Released 122
daeg writes "PHP 5.2.2 and 4.4.7 have been released with a plethora of security updates. Many of the security notifications come from the Month of PHP Bugs effort, and range from double freed memory to bugs in functions that allow attackers to enable register_globals, to memory corruption with unserialize(), to input validation flaws that allow e-mail header injections, with an unhealthy sprinkling of other bugs and flaws fixed. All administrators that run any version of PHP are encouraged to update immediately."
I want to see someone claim again (Score:5, Insightful)
Now if only could PHP also fix their performance and inconsistencies..
Bad release practices (Score:5, Insightful)
See, for example, the 4.6.6 release notes [php.net]:
Thank god Python doesn't do that. At least they keep all the big changes to individual versions!
Re:Bad release practices (Score:1, Insightful)
If you use register_globals, you deserve all bugs that hit you. Period.
Most of these bugs are completely preventable (Score:2, Insightful)
"double freed memory to bugs in functions that allow attackers to enable register_globals, to memory corruption with unserialize()"
The authors of php should use valgrind, and with a few test cases, could virtually eliminate memory errors.
Memory errors have been around for so long that there are numerous tools for dealing with them, many of them free. I know that many people on slashdot like to put down the importance of an education, but the knowledge, ability and discipline to use these tools is what separates professional software engineers from (generally smart) people who just hack at things.
Re:You must be mistaken. (Score:5, Insightful)
I'm a PHP developer. I love PHP because I haven't come across anything that I can not do with it yet. Does that mean it's the best programming language ZOMG 3V3R! No. PHP is a pretty good general purpose web scripting language. Like all the other languages out there, it has bugs or features that haven't been implemented or thought of yet, and that's why there are version numbers.
PHP does suffer some of the same issues that C++ has suffered in the past, and they are due to the fundamental ideas of the project. PHP doesn't have a framework for you to do everything. I guess that mostly comes up with ASP and probably Ruby, but I'm a little under read on Ruby. Much like the C++ vs. Java debate, C++ makes you do things yourself (or at least you need to know about the community projects that make life easier... like smart pointers and the like). That's pretty much the same with PHP. You have the base functions, and there are extensions you can get to help, but MVC and other parts of frameworks are left for you to decide what you want or need for your project.
So, with that in mind, security is also left up to the developer. PHP 5.2.x has made a lot of great strides in helping out by introducing the Filter extension and others. If people do not filter/escape the input/output from their pages, they're just opening up a can of worms. I'm a firm believer in saying it's easier to filter yourself than undo a filter that the system did for you automatically.
PHP has its issues, but I don't think it would be as popular as it is if PHP didn't serve a purpose and do it somewhat well.
Re:I want to see someone claim again (Score:1, Insightful)
What you're saying: PHP is only good for gluing your DB to your HTML, straight procedural code. But that was true in the distant (in IT terms) past of the web, before PHP programmers got educated enough to demand applications with proper architecture and provisions, manageable and stable code, versus the spaghetti code we see so often in old open source PHP projects.
Plus, go teach Zend about your view on their language. Their framework has terrible speed on their own language. Stupid Zend, doing stupid things.
You can't put randomly a line where something becomes "too complex for PHP" and where it's not. If PHP struggles for tasks fast enough for other comparable, means the problem isn't in the programmers. In the end PHP loses, by having an "elite" of folks who would rather stubbornly defend PHP's faults than do something about them.
Re:seriously ... (Score:3, Insightful)
Unfortunately, mod_php is still more programmer and administrator friendly than mod_perl, which probably explains why it has a higher usage rate.
Re:lipstick on a pig... (Score:1, Insightful)
If people like you were right, we'd all have ditched perl long ago because of the phf bug.
PHP, like any software has its holes, but a properly secured system isn't much more likely to be compromised than an IIS server.
Re:yeah yeah yeah (Score:3, Insightful)
PHP is getting better. They are cleaning up security issues, and providing more and more of a solid core of capabilities. I just wish that the users were more excited about these developments. I can't understand why so many continue to develop in PHP4. Every change and step forward gets a mixed response.
Personally, I'm all for breaking conventions if it will result in making PHP a better language. I wish that they would bite the bullet and rename all the functions to follow a consistent style in PHP6. Those who can't handle it can stick with 4 or 5, but let's look to the future and make PHP the best it can be.
Re:Examples of PHP inconsistency and performance (Score:5, Insightful)
This is my main beef with PHP. They have their head in the sand with regards to server configuration.
Case in point: the company I work for sells PHP-based service center and reservations systems to large companies. These companies generally have windows-based server infrastructures, so we have to deploy on windows/IIS. If you look at the suggested configuration for PHP on IIS in the PHP manual, you'll find this page [php.net], which explains regular CGI and ISAPI (multi-threaded) configurations. What the manual doesn't tell you is that neither of these configurations actually work in production environments. Regular CGI configurations are too slow (on windows), and ISAPI is too unreliable (customers that deployed with ISAPI configurations suffered daily server hangs).
The only viable configuration for production IIS servers, as it turns out, is FastCGI, which is not documented in PHP's manual section on IIS configuration. Their documentation actively misinforms people on how to configure PHP. That's bad.
Re:I want to see someone claim again (Score:3, Insightful)
Heck you can make a bash script output your website for you. Or even QBASIC.