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:
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.
(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
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.
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:
finance/php-tclink ( see bug 198778 )
A commit references this bug:
Date: Sat Mar 21 18:40:20 UTC 2015
New revision: 381813
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"
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.
A commit references this bug:
Date: Sat Mar 21 18:58:06 UTC 2015
New revision: 381814
databases/php53-redis: Deprecate, remove on 15 APR 2015
Remove with the rest of the php53 ports in ~4 weeks.
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:
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.
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)