| « Count The Costs | To stat() Or Not To stat()? » |
When the next version of Ubuntu is released on October 29th, PHP developers won’t be able to upgrade to PHP 5.3 through the included package management tools.
A meeting of the development team on July 30th nixed the inclusion of PHP 5.3 from inclusion in Karmic, the next iteration of Ubuntu for the desktop and the server. According to meeting minutes, there is concern amongst the Ubuntu security team that failure to include the suhosin patch in the PHP release would be a feature regression. Instead, the release will be referred to PPA until more testing can be completed.
It is unlikely that Ubuntu will see official PHP 5.3 support until April, 2010, based on the history of Ubuntu release cycles. However, you can still compile PHP 5.3 on Ubuntu yourself.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 8/4/2009 at 9:31 am
j wrote at 8/4/2009 11:51 am:
what’s everyone’s feeling on suhosin. i’ve got a couple ubuntu servers running in the wild, they’ve been great except the other day i ran into a problem trying to get apc’s rfc1867 working on ubuntu 9.04 5.2.6 suhosin.
http://pecl.php.net/bugs/bug.php?id=12314
if you’re not familiar with rfc1867, it’s the upload progress tracker built into apc.
Brandon Savage (@brandonsavage) wrote at 8/4/2009 2:12 pm:
I feel like if you code with the proper standards and close your security holes you’re less likely to be vulnerable. But you have to make that call for yourself, whether or not you’re capable of producing that kind of code.
g wrote at 8/4/2009 6:27 pm:
PHP5.3 is available in the dotdeb debian repo. Not sure exactly how it’d work on ubuntu though.
Andi Gutmans wrote at 8/5/2009 1:26 am:
We will be releasing PHP 5.3 DEB repositories for Ubuntu of Zend Server Community Edition in the coming weeks. This will not only deliver choice of 5.2 and 5.3 but also includes some value adds such as Optimizer+ (fastest and most reliable byte-code cache), Java connectivity, management UI, etc…
PHP 5.2 repositories for Ubuntu already are available…
Ben Ramsey (@ramsey) wrote at 8/5/2009 11:01 am:
If you’re unsure about compiling PHP on your own, you can also modify /etc/apt/sources.list to add references to experimental PHP 5.3 debs. Instructions are available here:
http://www.dotdeb.org/2009/07/03/php-5-3-0-final-preview-packages-available-for-debian-lenny/
After making that change, then you can install PHP 5.3 using apt-get or aptitude.
Giorgio Sironi (@giorgiosironi) wrote at 8/5/2009 11:03 am:
No flame intended, but installing php by yourself in that way (make install instead of building a deb package) will mess up the system and raise problems when a package will be available via apt-get.
No flame perceived.
One thing you can do is add a –prefix=/my/path and this will install PHP in a location of your choosing. Upon the release of the package, you can simply run a rm -fr /my/path and get rid of PHP.
Running your own server inherently comes with these risks, and I think most people who feel comfortable compiling PHP are also comfortable being systems administrators so far as to manage their own installations of things. Example: I manage my own installation of Subversion, and each time I do an update I have to reinstall some part of it. This creates some headaches, to be sure, but it’s part of having the latest version of things.
Fabry wrote at 8/5/2009 11:12 am:
PHP 5.3.0 is included in Fedora 12
https://fedoraproject.org/wiki/Fedora_12_Alpha_release_notes
Matt wrote at 8/5/2009 5:21 pm:
Why doesn’t the PHP team include sohosin instead of making all the distros patch it in for each release?
The patch compensates for poor development and security practices, and I’m sure that the core PHP developers feel as though they ought not reward that behavior by including the patch in the core. I, myself, don’t use the patch because of things it interferes with, and I think that if we boil it down a lot of developers would take offense at having to use a security patch that has features they don’t want or need, and that have a serious performance impact on PHP itself (sohosin does impact performance considerably in several areas).
Stefan Esser wrote at 8/6/2009 9:57 am:
Suhosin for PHP 5.3.0 will be released when I am finally at home again next week. Due to some of the new features in the patch it turned out to be a bigger task than expected and therefore it was not possible to release it before I left for conferences and vacation.
One of the new features will be a certain amount of protection against the PHP security holes I presented at Blackhat about. You won’t get this protection in vanilla PHP.
Federico (@fedecarg) wrote at 8/7/2009 12:13 pm:
Hi Brandon,
> and that have a serious performance impact on PHP itself (sohosin does impact performance considerably in several areas).
I think it should be optional as well, specially if it has a huge impact in performance, like you said. Do you have any benchmarks of this? Thanks.
Vladimir wrote at 8/11/2009 4:40 pm:
Has anyone tested the modified Suhosin patch from Arnold (http://blog.adaniels.nl/articles/suhosin-patch-for-php-53/)?
Sorry, the link is broken. Should be http://blog.adaniels.nl/articles/suhosin-patch-for-php-53/
I haven’t tried to apply the patch. I’m waiting for the official patch.
Kevin van Zonneveld (@kvz) wrote at 8/12/2009 6:05 am:
Correct me if I’m wrong. But I interpreted the meeting minutes slightly different.
“Once the suhosin patch is ported to 5.3 and enabled in the build 5.3 can be uploaded to karmic. ”
To me says: there’s still time to do the suhosin patch and then get in in Karmic. Given the fact that there already is an unofficial suhosin patch out there, I’m feeling chances are actually pretty good.
But I could be overlooking something.
Anyway, there’s something going on here as well:
https://bugs.launchpad.net/ubuntu/+source/php5/+bug/394385
You have to produce some benchmarks, otherwise there’s no reason for not using it. What you said about developers getting offended is nonsense.
I don’t “have” to produce anything. When even the makers of the patch admit that some features have a measurable speed impact (http://www.hardened-php.net/hphp/faq.html#general) insisting that I provide evidence when they’ve already admitted it makes you look like a fool. I’m not the one who says that Suhosin has a performance impact, the makers of Suhosin are. Q.E.D.
I’d like to know what on this list (http://www.hardened-php.net/hphp/a_feature_list.html) you think wouldn’t be already handled by making use of already established best practices. Suhosin provides a great set of features to make sure that a noob developer doesn’t run amok on your system, but a seasoned developer will avoid these practices by default.
Admit it. What you said about developers getting offended is nonsense. Maybe you got offended? Your boss installed the patched?
I’ll not be bullied into taking a position I know to be untrue, especially by small minds. I’ll also not restate my arguments, which I’ve already made.
I will say that I use Suhosin on my own server, due to the fact that I make use of WordPress and it’s plugins. I don’t have time to review every single line of WordPress code, nor do I have the desire to do so; instead I rely on the hardening patch to help defend the system.
| « Count The Costs | To stat() Or Not To stat()? » |