Bug 198150 - PHP 53 - 6 months EOL - this should not be in ports
Summary: PHP 53 - 6 months EOL - this should not be in ports
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Ports Security Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-02 09:19 UTC by John Marino
Modified: 2015-04-05 16:34 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Marino freebsd_committer 2015-03-02 09:19:37 UTC
I'm filing this under infrastructure so portmgr can make the call.

PHP 5.3 has been EOL from security fixes for six months already:
http://php.net/eol.php

In fact, PHP 5.4 has already ceased development and it's security fix EOL is Sept 2015, right around the corner

The maintainer is flo@.  I expressed my concern about this security vulnerability that FreeBSD is enabling by bypassing upstream's recommendation.  He said that somebody asked him to keep it in ports and would take responsibility for security updates.

I don't have faith in that approach.
Also, pkgsrc has removed PHP 5.3 from their collection for security reasons.

I think portmgr or a security officer needs to evaluate *specifically* if it's a good idea to keep PHP 5.3 in ports so long after it's official security EOL.

My opinion is that it should be deprecated for removal ASAP.
Comment 1 Chris Hutchinson 2015-03-02 14:44:18 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
Comment 2 Bernard Spil freebsd_committer 2015-03-03 09:22:07 UTC
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.
Comment 3 Harrison Grundy 2015-03-03 09:31:36 UTC
This seems like a good idea, unless someone wants to volunteer to port the RH fixes?
Comment 4 John Marino freebsd_committer 2015-03-03 09:37:01 UTC
(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.
Comment 5 John Marino freebsd_committer 2015-03-09 11:35:05 UTC
bapt says port-secteam guides on security matters, so assign the PR to them.
Comment 6 John Marino freebsd_committer 2015-03-21 18:11:33 UTC
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 )
Comment 7 commit-hook freebsd_committer 2015-03-21 18:40:43 UTC
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
Comment 8 commit-hook freebsd_committer 2015-03-21 18:58:46 UTC
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
Comment 9 Adam Major 2015-04-05 16:24:06 UTC
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
Comment 10 John Marino freebsd_committer 2015-04-05 16:34:49 UTC
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)