Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81665
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.214.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <d7b2a3b103b4bad34c70cf02365d8ff9.squirrel@webmail.klapt.com>
References: <cef015a176ff63284f81af24f1e3d774.squirrel@webmail.klapt.com>
	<CAF+90c-dG_jd2LrzbRT2+DXLi+oQj1sien7560KreKm-gQ=Cug@mail.gmail.com>
	<CAPhkiZw0Bqx_rgx6TO-W6Mmfza9L3qB6p6u-n3X_DXeCX2r+Zw@mail.gmail.com>
	<CAPhkiZwaPc6iLjezhhxmKUNE2fj17tN6s7nuL=mvK7NwN7RpBA@mail.gmail.com>
	<2ebcb8f91e4185726e4bf49d5e675c2a.squirrel@webmail.klapt.com>
	<CAPhkiZynQoD72NL7s1g2zZbck9uxOY2LLk33G5ExUE-M2fs8Sg@mail.gmail.com>
	<d7b2a3b103b4bad34c70cf02365d8ff9.squirrel@webmail.klapt.com>
Date: Tue, 3 Feb 2015 00:48:31 +0200
Message-ID: <CAPhkiZyxV5+Dzxzyw5Sbtx95dvsw_+Jem0yv3xFnfmwdaPHF8w@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported
 SAPIs and extensions
From: narf@devilix.net (Andrey Andreev)

Hi,

On Tue, Feb 3, 2015 at 12:16 AM, Anatol Belski <anatol.php@belski.net> wrote:
>>>>
>>>> Mcrypt might be dead, but removing it would be a huge BC break. There
>>>>  was some talk of binding mcrypt_*() functions to ext/openssl - I'd
>>>> suggest that instead of removal.
>>>>
>>> that sounds plausible, but the same one could say about mapping to be
>>> removed regex to pcre. If anything of that is going to be happening, so
>>> I
>>> would welcome another RFC and implementation.
>>>
>>
>> Not quite ... ereg has been deprecated since PHP 5.3, while mcrypt was
>> never deprecated and is extremely wide-spread in PHP code (that does
>> encryption) today.
>>
> yeah, looking at the openssl you've mentioned, and which was vulnerable to
> any possible attacks last years, and has fixed those ... Asking myself,
> how a library which wasn't updated since like eight years does feel :) Can
> it still provide that really secure encryption? And should one provide
> something like that as a secure solution?
>
> Comparing with regex I meant, one could provide a replacing API. Just
> where with regex it's more like functionality breach (whereby security as
> well, as that lib wasn't revisited maybe for much longer than mcrypt),
> with mcrypt it's a security weakness we would still try to sell for safe.
>

Well, obviously mcrypt *has* to go away at some point - there's no
doubt about it.

I'm just saying it would be a massive BC break if that happens with no
prior deprecation. If somebody has the motivation to make the userland
API bind to ext/openssl under the hood, that's just a bonus in at
least depending on maintained code.

Cheers,
Andrey.