Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81791
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
Message-ID: <dc01d0e2a2aa87c26a4669b2a20c14c2.squirrel@webmail.klapt.com>
In-Reply-To: <54D1C176.6000107@gmail.com>
References: <cef015a176ff63284f81af24f1e3d774.squirrel@webmail.klapt.com>
    <CADajX4DwhhPudqixn7Ck=LUKX9XH4mpdFgvADhF0tmXMPTYueQ@mail.gmail.com>
    <0d436102ec3afeeb91673e2d30c64de4.squirrel@webmail.klapt.com>
    <54D1C176.6000107@gmail.com>
Date: Wed, 4 Feb 2015 10:16:09 +0100
To: "Stanislav Malyshev" <smalyshev@gmail.com>
Cc: "Anatol Belski" <anatol.php@belski.net>,
 "Adam Harvey" <aharvey@php.net>,
 "PHP internals" <internals@lists.php.net>
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported
 SAPIs and extensions
From: anatol.php@belski.net ("Anatol Belski")

Hi Stas,

On Wed, February 4, 2015 07:51, Stanislav Malyshev wrote:
> Hi!
>
>
>> And at list this one living native PHP implementation
>> https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
>> more library links in the older thread link above).
>
> This is part of Horde with 9 listed dependencies and 9 suggested ones,
> and probably also sub-dependencies. It is much less convenient than having
> imap right here when you run PHP. And looks like on top of that it lists
> PHP 7 as not supported.
> I'm sure there are other imap implementations, but I wouldn't be that
> quick in throwing out one that a lot of people may use. --
> Stas Malyshev
> smalyshev@gmail.com
>
Horde is being developed by a some ISP, so it's mostlikely gonna support
PHP7, even if not already. But this is actually what one can say regarding
PHP7 compatibility with any scripts at the current stage.

For security tickets - there are still some on mitre, NVD and others.

The point with ext/imap being available "now and here" instead of the
userland implementation is of course good. However removing it has the
same reasons like f.e. removing ext/regex or Apache 1.x SAPI. Letting it
be there, unmaintained, is kinda of a black hole. And every day it grows.

That's why my point is rather - link to some userland implementation
instead of shipping "worky" stuff in the unknown security state. Same
actually for mcrypt. Probably the same motivation can be attributed to the
unavailability of libc-client and mcrypt in RHEL6.

Regards

Anatol