3 ms·

This drives me crazy: we have a billion-dollar business as a client who self-hosts their website, and it's running on PHP 5.3.3 on a way outdated version of Cen

by trebor 12y ago

This drives me crazy: we have a billion-dollar business as a client who self-hosts their website, and it's running on PHP 5.3.3 on a way outdated version of CentOS. It's not as if they can't afford to upgrade, it's that they won't. We have other clients who won't leave their host, and we're locked to PHP 5.2 to try to "write a modern application" in. The bleeding edge may not be safe, but staying locked to an ancient copy of PHP 5 that was end-of-lifed years ago is not a smart idea.

gdulli 12y ago
PHP has thrived due to the mindset of wanting to get pages on the web with the least amount of effort to configure or understand the stack. It's what I've always seen people cite as the reason for adopting PHP. The language isn't simple, it's full of inconsistency, but the deployment is simple, the setup is simple with default Apache and mod_php, the 1:1 correspondence between web pages and files on the filesystem is simple. It should be expected that the same mindset would lead to unpatched servers and inattention to the nuances of the stack.
- trebor 12y ago
  Actually, this company has their own internal development team that doesn't use PHP. They also employ full-time sysadmins. The only reason they used PHP is because they wanted to use a very well known CMS. We were explicitly told to conform to their server specs with our vagrant box to ensure compatibility, etc. So PHP was adopted to support the CMS, and I guess their sysadmin never bothered to upgrade the server. I wouldn't the cause of this unpatched server to inattention. More like bureaucracy and a bad case of "too many cooks in the kitchen".
  - benjarrell 12y ago
    Speaking as sysadmin, I have inherited situations similar to what you describe. It could be laziness, but I have also encountered program/project managers that put so many obstacles that it makes you throw your hands up. Having a manager that will back you up makes difference. I've come to the conclusion that inertia is the most powerful force in business.
xyby 12y ago
Which industry are they in?
- trebor 12y ago
  The Hospitality (Hotel/Resort/Etc) industry. Edit: I don't know if I can reveal the client, so please don't ask.
Alupis 12y ago
> and it's running on PHP 5.3.3 on a way outdated version of CentOS That's probably not as bad as you make it out to be. CentOS 5.x is supported through 2017 with security patches, as would be CentOS/RHEL's customized PHP package. You don't get the new features, but you get the back-ported security fixes. And if you want a newer version of PHP, you can always use IUS Community's repos[1] > The IUS Community Project is a brain child of the RPM Development Team at Rackspace Hosting. Since 2006, we have provided and maintain packages for the latest versions of PHP/MySQL and other common software on Red Hat Enterprise Linux, because a lot of our customers strongly demand it. Internally we maintain a number of package sets for an audience of thousands of production servers. Until now, these packages have only been available internally to Rackspace customers. After a while we started thinking: Why not make this available publicly for everyone to benefit? [1] https://iuscommunity.org/pages/About.html https://iuscommunity.org/pages/About.html
smsm42 12y ago
The bleeding edge is getting pretty safe now, BC considerations being a major concern since 5.4 - which basically boils down to "if it works differently, it doesn't get into 5.x unless it's a security fix or obvious bugfix". If you look at the list of BC-breaking changes in 5.5[1] and in 5.6[2], it is very small. As for supporting 5.2, I think people should start plain refusing to support outdated versions and educate their clients that running this version puts their business at risk. Unless there's super-important reasons for it (like the only supported PHP version for PrivateWeirdOS is 5.2 and nobody can port any supported version to it because the effort takes years), there should be no development targeting version that was EOLed 4 years ago. [1] https://github.com/php/php-src/blob/PHP-5.5/UPGRADING https://github.com/php/php-src/blob/PHP-5.5/UPGRADING [2] https://github.com/php/php-src/blob/PHP-5.6/UPGRADING https://github.com/php/php-src/blob/PHP-5.6/UPGRADING
r0s 12y ago
You don't sound like a developer, more IT/ops side so let me try to put this in perspective. The existing security holes in their code are going to be given equal weight with these concerns. Now unless you know what their bugfix backlog is, there's no reason to think security upgrades are a bigger priority than say PCI audits or whatever. Unless there's a demonstrable value to fix this OVER all other security issues, only then would it make sense to hustle with a emergency fix. And the thing about emergency patching is that you can't just toss your "solution" into the product. At the very starting line of sanity you need to research the risk an upgrade will have on your system. Don't think of the environment the system is hosted on, but the code itself. That takes someone really smart and expensive to get pulled off whatever they were working on that generates money and focus on this security issue (over all others). They research, document and propose an upgrade path. Code will need to be refactored, tested system wide and then QA/UAT will chew on it. Data may need to be migrated or transformed (in production, risky!). And that's all if they know the right way to do it! If you're unlucky you get a panicking CTO or boss who (read this article on hacker news and) demands a quick fix. In that case you upgrade the server, throw code up and fix related bugs for months. Who knows, maybe none of them will be security holes!

by trebor 12y ago

gdulli 12y ago

PHP has thrived due to the mindset of wanting to get pages on the web with the least amount of effort to configure or understand the stack. It's what I've always seen people cite as the reason for adopting PHP. The language isn't simple, it's full of inconsistency, but the deployment is simple, the setup is simple with default Apache and mod_php, the 1:1 correspondence between web pages and files on the filesystem is simple. It should be expected that the same mindset would lead to unpatched servers and inattention to the nuances of the stack.

trebor 12y ago
Actually, this company has their own internal development team that doesn't use PHP. They also employ full-time sysadmins. The only reason they used PHP is because they wanted to use a very well known CMS. We were explicitly told to conform to their server specs with our vagrant box to ensure compatibility, etc. So PHP was adopted to support the CMS, and I guess their sysadmin never bothered to upgrade the server. I wouldn't the cause of this unpatched server to inattention. More like bureaucracy and a bad case of "too many cooks in the kitchen".
- benjarrell 12y ago
  Speaking as sysadmin, I have inherited situations similar to what you describe. It could be laziness, but I have also encountered program/project managers that put so many obstacles that it makes you throw your hands up. Having a manager that will back you up makes difference. I've come to the conclusion that inertia is the most powerful force in business.

xyby 12y ago

Which industry are they in?

trebor 12y ago
The Hospitality (Hotel/Resort/Etc) industry. Edit: I don't know if I can reveal the client, so please don't ask.

Alupis 12y ago

> and it's running on PHP 5.3.3 on a way outdated version of CentOS That's probably not as bad as you make it out to be. CentOS 5.x is supported through 2017 with security patches, as would be CentOS/RHEL's customized PHP package. You don't get the new features, but you get the back-ported security fixes. And if you want a newer version of PHP, you can always use IUS Community's repos[1] > The IUS Community Project is a brain child of the RPM Development Team at Rackspace Hosting. Since 2006, we have provided and maintain packages for the latest versions of PHP/MySQL and other common software on Red Hat Enterprise Linux, because a lot of our customers strongly demand it. Internally we maintain a number of package sets for an audience of thousands of production servers. Until now, these packages have only been available internally to Rackspace customers. After a while we started thinking: Why not make this available publicly for everyone to benefit? [1] https://iuscommunity.org/pages/About.html https://iuscommunity.org/pages/About.html

smsm42 12y ago

The bleeding edge is getting pretty safe now, BC considerations being a major concern since 5.4 - which basically boils down to "if it works differently, it doesn't get into 5.x unless it's a security fix or obvious bugfix". If you look at the list of BC-breaking changes in 5.5[1] and in 5.6[2], it is very small. As for supporting 5.2, I think people should start plain refusing to support outdated versions and educate their clients that running this version puts their business at risk. Unless there's super-important reasons for it (like the only supported PHP version for PrivateWeirdOS is 5.2 and nobody can port any supported version to it because the effort takes years), there should be no development targeting version that was EOLed 4 years ago. [1] https://github.com/php/php-src/blob/PHP-5.5/UPGRADING https://github.com/php/php-src/blob/PHP-5.5/UPGRADING [2] https://github.com/php/php-src/blob/PHP-5.6/UPGRADING https://github.com/php/php-src/blob/PHP-5.6/UPGRADING

r0s 12y ago

You don't sound like a developer, more IT/ops side so let me try to put this in perspective. The existing security holes in their code are going to be given equal weight with these concerns. Now unless you know what their bugfix backlog is, there's no reason to think security upgrades are a bigger priority than say PCI audits or whatever. Unless there's a demonstrable value to fix this OVER all other security issues, only then would it make sense to hustle with a emergency fix. And the thing about emergency patching is that you can't just toss your "solution" into the product. At the very starting line of sanity you need to research the risk an upgrade will have on your system. Don't think of the environment the system is hosted on, but the code itself. That takes someone really smart and expensive to get pulled off whatever they were working on that generates money and focus on this security issue (over all others). They research, document and propose an upgrade path. Code will need to be refactored, tested system wide and then QA/UAT will chew on it. Data may need to be migrated or transformed (in production, risky!). And that's all if they know the right way to do it! If you're unlucky you get a panicking CTO or boss who (read this article on hacker news and) demands a quick fix. In that case you upgrade the server, throw code up and fix related bugs for months. Who knows, maybe none of them will be security holes!