Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 5 and 7.0 end of life

hackertarget.com

Post reply on HN
Print view View original

11–20 of 122 posts

Re: PHP 5 and 7.0 end of life

#11

Post by naranha »

TazeTSchnitzel wrote: post #10
naranha wrote: post #7

Somebody should fork PHP 5.6. There is a lot of Software still depending on it and it is unrealistic to expect companies to migrate millions of lines of third party code to PHP 7.

PHP 7's changes shouldn't affect most 5.6 code, and the code that is affected should not be difficult to fix. It's not supposed to be a Python 2/3 situation.

In theory, yes. However as the Germans say "the devil is in the details". The .patch file for magento 1 for PHP7 compatibility is around 1.9 MB (iirc)! In the standard PHP5 project you have literally millions of lines of third party code, that one shold not touch with a stick. Are you really going through all of this code to check if something is maybe going to break at runtime? What if the legacy project has 0 tests?

Another problem are the Docker images. The PHP project still provides Docker Images for 5.6, however to my knowledge they are not updated anymore (perhaps I'm wrong). So what about all the security vulnerabilities in the underlying linux image? (I just verified and the latest php 5.6 image is from January 2019)

Re: PHP 5 and 7.0 end of life

#14

Post by rgoulter »

naranha wrote: post #11
TazeTSchnitzel wrote: post #10

Earlier quoted context omitted.

PHP 7's changes shouldn't affect most 5.6 code, and the code that is affected should not be difficult to fix. It's not supposed to be a Python 2/3 situation.

In theory, yes. However as the Germans say "the devil is in the details". The .patch file for magento 1 for PHP7 compatibility is around 1.9 MB (iirc)! In the standard PHP5 project you have literally millions of lines of third party code, that one shold not touch with a stick. Are you really going through all of this code to check if something is maybe going to break at runtime? What if the legacy project has 0 tests…

What situation are you in where security vulnerabilities in the Docker image are important to fix, but updating from End-of-Life support for the language isn't? (Or even where security of an old Docker image is important, but "has 0 tests" isn't a concern?).

That being said, using a newer underlying Linux image for a Docker image is as copying the Dockerfile and building it, isn't it?

Re: PHP 5 and 7.0 end of life

#16

Post by naranha »

rgoulter wrote: post #14
naranha wrote: post #11

Earlier quoted context omitted.

In theory, yes. However as the Germans say "the devil is in the details". The .patch file for magento 1 for PHP7 compatibility is around 1.9 MB (iirc)! In the standard PHP5 project you have literally millions of lines of third party code, that one shold not touch with a stick. Are you really going through all of this code to check if something is maybe going to break at runtime? What if the legacy project has 0 tests…

What situation are you in where security vulnerabilities in the Docker image are important to fix, but updating from End-of-Life support for the language isn't? (Or even where security of an old Docker image is important, but "has 0 tests" isn't a concern?). That being said, using a newer underlying Linux image for a Docker image is as copying the Dockerfile and building it, isn't it?

Sure all these problems are important to address. But often there is a lack of time/interest to do it.

I think the PHP project should simply delete the 5.6 image, since it is insecure and EOL'ed. Then if somebody is interested they can provide an alternative image somewhere...

Re: PHP 5 and 7.0 end of life

#17

Post by trilila »

johnchristopher wrote: post #6

Yeah, yeah. Go tell that to my 10x php self-taught guy who's still running php 5.4 on a windows server 2003 in a wamp installation. He upgraded the bundled mysql with mariadb last year by dropping the executable in the folder (edit: just checked out, and the drop-in has been reverted back to mysql 5.0 because the upgrade path is impossible because apache 2.2). And of course this in-house guru for anything that happen…

The issue with PHP is devs like that guy.

Re: PHP 5 and 7.0 end of life

#18

Post by trilila »

naranha wrote: post #11
TazeTSchnitzel wrote: post #10

Earlier quoted context omitted.

PHP 7's changes shouldn't affect most 5.6 code, and the code that is affected should not be difficult to fix. It's not supposed to be a Python 2/3 situation.

In theory, yes. However as the Germans say "the devil is in the details". The .patch file for magento 1 for PHP7 compatibility is around 1.9 MB (iirc)! In the standard PHP5 project you have literally millions of lines of third party code, that one shold not touch with a stick. Are you really going through all of this code to check if something is maybe going to break at runtime? What if the legacy project has 0 tests…

Magento is not exactly known for well written code, actually it is full of anti patterns and antiqued practices. PHP 7 was released in 2015, and if authors of those millions of lines of code can't be bothered to upgrade then probably their code should not be used.

Re: PHP 5 and 7.0 end of life

#19

Post by naranha »

trilila wrote: post #18
naranha wrote: post #11

Earlier quoted context omitted.

In theory, yes. However as the Germans say "the devil is in the details". The .patch file for magento 1 for PHP7 compatibility is around 1.9 MB (iirc)! In the standard PHP5 project you have literally millions of lines of third party code, that one shold not touch with a stick. Are you really going through all of this code to check if something is maybe going to break at runtime? What if the legacy project has 0 tests…

Magento is not exactly known for well written code, actually it is full of anti patterns and antiqued practices. PHP 7 was released in 2015, and if authors of those millions of lines of code can't be bothered to upgrade then probably their code should not be used.

> Magento is not exactly known for well written code

As are many/most PHP 5.6 projects

> Probably their code should not be used.

In reality it is - unfortunately. And many smaller companies don't have the capacity to change.

Re: PHP 5 and 7.0 end of life

#20

Post by vbsteven »

naranha wrote: post #16
rgoulter wrote: post #14

Earlier quoted context omitted.

What situation are you in where security vulnerabilities in the Docker image are important to fix, but updating from End-of-Life support for the language isn't? (Or even where security of an old Docker image is important, but "has 0 tests" isn't a concern?). That being said, using a newer underlying Linux image for a Docker image is as copying the Dockerfile and building it, isn't it?

Sure all these problems are important to address. But often there is a lack of time/interest to do it. I think the PHP project should simply delete the 5.6 image, since it is insecure and EOL'ed. Then if somebody is interested they can provide an alternative image somewhere...

Plainly deleting the image will cause existing setups to break. Something like `cargo yank` would be more appropriate where you can still download the version for existing projects but you cannot use it in new projects anymore. Unfortunately as far as I know docker has no support for anything like that.
Post reply on HN