Hi, On Tue, Feb 3, 2015 at 12:16 AM, Anatol Belski <anatol....@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
