On Tue, Mar 22, 2016 at 2:21 PM, Nikita Popov <nikita....@gmail.com> wrote:
> On Tue, Mar 22, 2016 at 6:00 PM, Scott Arciszewski <sc...@paragonie.com> > wrote: > >> Hi all, >> >> https://wiki.php.net/rfc/mcrypt-viking-funeral >> >> The tally of closing (2016-03-22T17:00:00) is 23 Yes, 6 No. This is a >> 79.3% >> favorable response, which exceeds the 2/3 majority by a significant >> margin. >> >> Thanks to everyone who voted or participated in this discussion. >> >> I've heard and respect some of the objections raised by folks who voted >> No, >> but moving this liability out of the core into PECL as soon as possible is >> not only a good move for the security of PHP applications, but now we know >> it's the choice the community wants. >> >> As promised, I'll get the E_DEPRECATED patch written soon. >> >> Additionally, I will have a decrypt-only mcrypt polyfill project written >> hopefully before 7.1.0-alpha but definitely before 7.1.0. This will allow >> people to migrate towards something better, e.g. >> openssl_encrypt()/openssl_decrypt(). >> > > I wonder if we should retain support mcrypt_create_iv(), while dropping > the rest of mcrypt. mcrypt_create_iv(), while being prefixed with mcrypt_, > has absolutely nothing to do with libmcrypt, it only landed in that > namespace out of convenience. Prior to PHP 7 it was probably the best > source of cryptographically strong randomness in PHP. > > Nikita > Given that mcrypt_create_iv() was part of the extension (which was actively maintained) and not part of the library (which was abandonware), it would be in the spirit of what was voted on to keep it (at least as an alias for random_bytes()). However, that was not covered by what everyone voted for. How would you like to proceed? Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com/>
