Bug 198150
| Summary: | PHP 53 - 6 months EOL - this should not be in ports | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | John Marino <marino> |
| Component: | Ports Framework | Assignee: | Ports Security Team <ports-secteam> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | adirmj, brnrd, harrison.grundy, portmaster, portmgr |
| Priority: | --- | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198778 | ||
|
Description
John Marino
2015-03-02 09:19:37 UTC
(In reply to John Marino from comment #0) > > My opinion is that it should be deprecated for removal ASAP. FWIW, I'd like to add a +1 here --Chris Not considering systemd refuguees that come from RHEL/CentOS 6.x that want to have PHP 5.3.3 I do +1 this. We should not have software in ports that don't get security fixes. This seems like a good idea, unless someone wants to volunteer to port the RH fixes? (In reply to Harrison Grundy from comment #3) In theory, this promise has vaguely been made although it is practically impossible to continuously enforce. The proposal also implicitly establishes RH as a security authority on PHP -- meaning the assumption is they are aware of *all* security holes in PHP 5.3 and patch them all. Frankly I don't trust RH to do this and even if I did, I don't trust all their patches to get into PHP 5.3 here in a timely and acceptable fashion. Where's the proof that this is happening now? We should be equivalent with PHP 53 in RH/Centos right now if it were happening, right? Are we? The safe play is to purge this version. bapt says port-secteam guides on security matters, so assign the PR to them. the maintainer (flo) dropped maintainership all PHP53 ports. re: https://svnweb.freebsd.org/ports?view=revision&revision=381799 I think this means there is no longer a decision to make, the ports must be removed with minimum notice (I'm picking 15 APR 2015) per INDEX grep/awking, there are only 8 ports that aren't php53-* ports. Six of those are pecl- ports. That leaves two non-pecl/php ports: databases/sqlitemanager (unmaintained) finance/php-tclink ( see bug 198778 ) A commit references this bug: Author: marino Date: Sat Mar 21 18:40:20 UTC 2015 New revision: 381813 URL: https://svnweb.freebsd.org/changeset/ports/381813 Log: php53 and fallout: Deprecate, set removal for 15 APR 2015 The PHP developers stopped providing security patches for the 5.3 branch on 14 August 2014. They "strongly urge" to upgrade to current versions "as using older versions may expose you to security vulnerabilities and bugs that have been fixed in more recent versions" of PHP. The PHP53 branch was released from maintainership today, so it's being deprecated with removal set for 15 April 2015. There were only 8 ports limited to php53, six of which were pecl- ports. These ports must be upgraded to use a later version of php (5.6 is recommended) soon, or they will be removed with php53. Note that all 8 ports incorrectly set the PHP_DEFAULT_VERSION, so this was changed to use IGNORE_WITH_PHP instead while here. PR: 198150 Changes: head/databases/sqlitemanager/Makefile head/devel/pecl-uuid/Makefile head/finance/php-tclink/Makefile head/german/pecl-konto_check/Makefile head/graphics/pecl-imlib2/Makefile head/lang/php53/Makefile head/lang/php53-extensions/Makefile head/print/pecl-ps/Makefile head/security/pecl-crack/Makefile head/www/pecl-amfext/Makefile A commit references this bug: Author: marino Date: Sat Mar 21 18:58:06 UTC 2015 New revision: 381814 URL: https://svnweb.freebsd.org/changeset/ports/381814 Log: databases/php53-redis: Deprecate, remove on 15 APR 2015 Remove with the rest of the php53 ports in ~4 weeks. PR: 198150 Changes: head/databases/php53-redis/Makefile Hello Please consider not removing the port PHP 5.3. (for few more months needed to inform people to need to re-writeln old scripts). Usage statistics for PHP 5.* versions is very interesting: http://w3techs.com/technologies/details/pl-php/5/all PHP 5.3 is still using 43.2% of market. 5.4 only 28.9%. Some people do not update PHP to 5.4 due to incompatibility between versions. The problems are with the old not quite well-written scripts (not from ports). If someone comes to reinstall the server (with many incompatible scripts) lack PHP 5.3 port (even with some security vulnerabilities) will be a big problem. Yes I know that the world goes forward versions too, but the statistics (if accurate) also show something. Thank you This topic has been covered on private email. considered - no justification to keep it (reason of bad sysadmins that refuse to follow EOL and adjust for custom non-ports software is not compelling. It also completely disregards the reason for removal -- lack of security) |