Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82394
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <80E6AA15-23FA-4A77-B50E-6819120E7B58@gmail.com>
References: <bc6d032454578020cdd2cef172698534.squirrel@webmail.klapt.com> <80E6AA15-23FA-4A77-B50E-6819120E7B58@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Tue, 10 Feb 2015 21:55:19 +0000
To: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <8F90E56D-CB77-47F2-B2C1-91CEA95CD5C0@gmail.com>
Subject: Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions
From: rowan.collins@gmail.com (Rowan Collins)

On 10 February 2015 21:38:02 GMT, David Muir <davidkmuir@gmail.com> wrote:
>
>> On 10 Feb 2015, at 9:29 am, "Anatol Belski" <anatol.php@belski.net>
>wrote:
>> 
>> Hi,
>> 
>> the voting on the removals in PHP7 in hereby finished. The results
>are
>> 
>> 
>> item                   yes:no
>> 
>> sapi/aolserver         32:0
>> sapi/apache            32:0
>> sapi/apache_hooks      31:0
>> sapi/apache2filter     23:1
>> sapi/caudium           30:0
>> sapi/continuity        28:0
>> sapi/isapi             28:0
>> sapi/milter            10:9
>> sapi/phttpd            26:0
>> sapi/pi3web            24:0
>> sapi/roxen             23:0
>> sapi/thttpd            25:0
>> sapi/tux               25:0
>> sapi/webjames          25:0
>> ext/imap               14:19
>> ext/mcrypt             15:18
>> ext/mssql              17:13
>> ext/pdo_dblib          4:18
>> ext/sybase_ct          17:1
>> 
>> As most of the items are considered to be removed, the ones to stay
>> untouched by the 50%+1 requirement are
>> 
>> ext/imap
>> ext/mcrypt
>> ext/pdo_dblib
>> 
>> I'm going to implement and tag the changes considered ASAP. Regarding
>the
>> stuff to considered to be removed from the core - if there are some
>> supporters, the sources will be made available in the git tag. They
>can be
>> anytime ported to PHP7 and possibly resurrected.
>> 
>> Regards
>> 
>> Anatol
>> 
>> 
>> 
>> 
>> -- 
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>
>Does this mean PHP will be taking on the role of maintaining libmcrypt
>as well? If a security issue is found, what is the course of action?

It means people want to find some more friendly way of moving forward rather than deleting the extension and letting users deal with the consequences.

I don't think anyone has suggested maintaining the underlying library. Several have suggested attempting to build at least a partial compatibility layer on top of openssl or other maintained libraries. Others have suggested adding aggressive warnings whenever the extension is used. I'm sure more suggestions will follow.

What is clear is that *something* should be done, but that consensus was that simple removal was not appropriate in this case.

Regards,
-- 
Rowan Collins
[IMSoP]