in Community, PHP 5

PHP 5.3 Not In Next Version Of Ubuntu

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.

Frustrated with your company’s development practices?

You don't have to be!

No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist.

Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."

Powered by ConvertKit


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

    if you’re not familiar with rfc1867, it’s the upload progress tracker built into apc.

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

  3. PHP5.3 is available in the dotdeb debian repo. Not sure exactly how it’d work on ubuntu though.

  4. 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…

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

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

  7. Why doesn’t the PHP team include sohosin instead of making all the distros patch it in for each release?

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

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

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

  11. 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:

  12. You have to produce some benchmarks, otherwise there’s no reason for not using it. What you said about developers getting offended is nonsense.

  13. I don’t “have” to produce anything. When even the makers of the patch admit that some features have a measurable speed impact ( 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 ( 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.

  14. Admit it. What you said about developers getting offended is nonsense. Maybe you got offended? Your boss installed the patched?

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

Comments are closed.