Re: [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions

From: Date: Mon, 02 Feb 2015 22:16:21 +0000
Subject: Re: [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-81661@lists.php.net to get a copy of this message
Hi, On Mon, February 2, 2015 22:39, Andrey Andreev wrote: > Hi, > > > On Mon, Feb 2, 2015 at 9:45 PM, Anatol Belski <anatol.php@belski.net> > wrote: > >> On Mon, February 2, 2015 20:30, Andrey Andreev wrote: >> >>> Oh, forgot one thing ... >>> >>> >>> >>> 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. Regards Anatol.

« previous php.internals (#81661) next »