Hi, On Mon, February 2, 2015 22:39, Andrey Andreev wrote: > Hi, > > > On Mon, Feb 2, 2015 at 9:45 PM, Anatol Belski <anatol....@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
