Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91856
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKws9z0ahvvd8z=Y5nSH8EmZPgA-6VMmOMsrc-SZSaPGb28Y-g@mail.gmail.com>
References: <CAKws9z0ahvvd8z=Y5nSH8EmZPgA-6VMmOMsrc-SZSaPGb28Y-g@mail.gmail.com>
Date: Tue, 22 Mar 2016 19:21:11 +0100
Message-ID: <CAF+90c_im1igitq9UJRXQ7UknmOSbE-_b_+bGpKvgAZd6585_w@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11409d1420bffb052ea747d8
Subject: Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11409d1420bffb052ea747d8
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 22, 2016 at 6:00 PM, Scott Arciszewski <scott@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

--001a11409d1420bffb052ea747d8--