Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6) »

[RFC][VOTE] Deprecate then Remove Mcrypt Closed (23-6)

php.internals

Scott Arciszewski

10 years ago
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(). Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com>

Ferenc Kovacs

10 years ago
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(). > > Scott Arciszewski > Chief Development Officer > Paragon Initiative Enterprises <https://paragonie.com> >
You ignored the voting process and my headsup mail about it, and also ignored most of the feedback from the replies.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Scott Arciszewski

10 years ago
On Tue, Mar 22, 2016 at 1:41 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> > > 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(). >> >> Scott Arciszewski >> Chief Development Officer >> Paragon Initiative Enterprises <https://paragonie.com> >> > > You ignored the voting process and my headsup mail about it, and also > ignored most of the feedback from the replies. > > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu >
​Let's go line by line, then? 1. Email internals@lists.php.net to measure reaction to your intended proposal. 2. Get wiki RFC karma Already had that. ​ ​3. ​Create the RFC Yes, obviously, I did that. :) 4. When your RFC is ready for discussion: * Change the status of your RFC page to “Under Discussion” Check. * Change its section on https://wiki.php.net/RFC to “Under Discussion” Totally fair to cry foul on this one; I did not do this. I wasn't aware of this step, otherwise I would have. * Send email to internals@lists.php.net introducing your RFC. I did this two months ago. 5. Listen to the feedback, and try to answer/resolve all questions. ​There were no substantial questions that needed to be addressed/resolved. People expressed concerns, but if we blocked every RFC because someome has a concern that doesn't form a substantive question, would we ever get anything done? 6. When discussion ends, and a minimum period of two weeks has passed since you mailed internals@lists.php.net in step 4, then you can move your RFC to “Voting” status. Two months >= two weeks. So really, I didn't "ignore the voting process", but I did miss a couple of details. Pardon my novice mistake. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com/>​

Rowan Collins

10 years ago
Scott Arciszewski wrote on 22/03/2016 18:09:
> 1. Emailinternals@lists.php.net to measure reaction to your intended > proposal.
This bit was definitely done, here: http://marc.info/?l=php-internals&m=145218573626243&w=2
> * Send email tointernals@lists.php.net introducing your RFC. > > I did this two months ago.
This is the step that Ferenc is saying doesn't appear to have happened. There's no mention of the RFC in that discussion thread, and I can't see any post from you on the subject between you creating the wiki page (on 9th Jan) and putting it to vote (on 15th March). You then proceeded to clarify the RFC while voting was open, which is what the initial discussion period is intended to avoid - all of these edits could and should have been included before people were asked to vote: https://wiki.php.net/rfc/mcrypt-viking-funeral?do=diff&rev2%5B0%5D=1458057988&rev2%5B1%5D=1458149335&difftype=sidebyside I'm not accusing you of any malicious intent, but I do agree with Ferenc that the vote seems to have been rather rushed through, and I'm not sure why you passed up his suggestion of cancelling the vote to tighten up the RFC. PHP 7.1 isn't going to come out any time soon, and deprecation is a tiny change anyway, so there's really no hurry. :) Regards,
-- Rowan Collins [IMSoP]

Ferenc Kovacs

10 years ago
On Tue, Mar 22, 2016 at 7:09 PM, Scott Arciszewski <scott@paragonie.com> wrote:
> On Tue, Mar 22, 2016 at 1:41 PM, Ferenc Kovacs <tyra3l@gmail.com> wrote: > >> >> >> 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(). >>> >>> Scott Arciszewski >>> Chief Development Officer >>> Paragon Initiative Enterprises <https://paragonie.com> >>> >> >> You ignored the voting process and my headsup mail about it, and also >> ignored most of the feedback from the replies. >> >> >> -- >> Ferenc Kovács >> @Tyr43l - http://tyrael.hu >> > > ​Let's go line by line, then? > > 1. Email internals@lists.php.net to measure reaction to your intended > proposal. > > 2. Get wiki RFC karma > > Already had that. > ​ > ​3. ​Create the RFC > > Yes, obviously, I did that. :) > > 4. When your RFC is ready for discussion: > > * Change the status of your RFC page to “Under Discussion” > > Check. > > * Change its section on https://wiki.php.net/RFC to “Under Discussion” > > Totally fair to cry foul on this one; I did not do this. I wasn't aware of > this step, otherwise I would have. > * Send email to internals@lists.php.net introducing your RFC. > > I did this two months ago. >
As I mentioned in my mail in the voting thread I couldn't find any email from you to the list with the link to the rfc, still waiting for your reply to show me that mail.
> > 5. Listen to the feedback, and try to answer/resolve all questions. > > ​There were no substantial questions that needed to be addressed/resolved. > People expressed concerns, but if we blocked every RFC because someome has > a concern that doesn't form a substantive question, would we ever get > anything done? >
It was brought up that the rfc should be clear about what it is targeting, voting shouldn't happen without an explicit target version, as we have different rules and expectations for a minor than a major version. For the record our release process rfc sucks a bit in this regard( https://wiki.php.net/rfc/releaseprocess), because it states that BC breaks shouldn't happen in a minor version, but it explicitly allows moving exts from core to pecl even though that this could cause userland impact (for example ext is moved to pecl then some internal API is changed in the core (which can also happen in a minor version) and the pecl extension doesn't receive an update so pecl install won't work out of the box). This means that technically you can target both 7.2 or 8.0 with your rfc for moving mcrypt to pecl but people would vote differently depending of what version do you pick for the rfc to target.
> > 6. When discussion ends, and a minimum period of two weeks has passed > since you mailed internals@lists.php.net in step 4, then you can move > your RFC to “Voting” status. > > Two months >= two weeks. >
see above, nobody seen your rfc page or commented on it before you linked it from your voting thread. Heck, as far as I can tell, it wasn't even listed on https://wiki.php.net/rfc before you put it up for voting. For the record I would probably vote yes for this proposal regardless of your answers on the feedback, I just want to have the process followed properly.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Nikita Popov

10 years ago
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

Scott Arciszewski

10 years ago
On Tue, Mar 22, 2016 at 2:21 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> 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 >
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/>​

Stas Malyshev

10 years ago
Hi!
> 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?
I'd say keep it - either as an alias of as a function, doesn't matter. It looks like common sense BC measure and doesn't seem to hurt anything. If we'll be moving whole extension out to PECL, we could keep this particular function as an alias.
-- Stas Malyshev smalyshev@gmail.com

Scott Arciszewski

10 years ago
No objections here. On Mar 22, 2016 3:23 PM, "Stanislav Malyshev" <smalyshev@gmail.com> wrote:

Andrey Andreev

10 years ago
Hi, On Tue, Mar 22, 2016 at 9:23 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi! > > > 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? > > I'd say keep it - either as an alias of as a function, doesn't matter. > It looks like common sense BC measure and doesn't seem to hurt anything. > If we'll be moving whole extension out to PECL, we could keep this > particular function as an alias. > >
While keeping it as an alias wouldn't be the worst thing ... I disagree, exactly because the whole extension is moved to PECL. mcrypt isn't an extension enabled by default and I'm yet to see a piece of code that doesn't do one of the following checks before calling mcrypt_create_iv(): - function_exists('mcrypt_create_iv') - extension_loaded('mcrypt') - defined('MCRYPT_DEV_URANDOM') // or another MCRYPT_* constant Unless of course it's a part of a library that explicitly depends on ext/mcrypt being enabled. So ... I don't see this alias really helping more than a handful of people. Cheers, Andrey.

Christoph Becker

10 years ago
Hi Scott! On 22.03.2016 at 18:00, Scott Arciszewski wrote:
> 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.
Any news here? PHP 7.1.0beta1 has been scheduled for July 19th, which is feature freeze.
-- Christoph M. Becker

Leigh

9 years ago
On 22 March 2016 at 17:00, 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.
As we're now at RC1, I assume it is too late to push forward with this?

Davey

9 years ago
I would still be OK adding this in RC2, TBH. I didn't realize it was missed, and it's something we _need_ to do. - Davey On Fri, Sep 2, 2016 at 8:08 AM, Leigh <leight@gmail.com> wrote:

Scott Arciszewski

9 years ago
I thought someone beat me to it? Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com> On Fri, Sep 2, 2016 at 11:18 AM, Davey Shafik <davey@php.net> wrote:

Scott Arciszewski

9 years ago
https://github.com/php/php-src/pull/1996 Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com> On Fri, Sep 2, 2016 at 11:18 AM, Scott Arciszewski <scott@paragonie.com> wrote:

Davey

9 years ago
That would be why I thought it hadn't been missed! Thanks Scott (and Christoph :) - Davey On Fri, Sep 2, 2016 at 8:19 AM, Scott Arciszewski <scott@paragonie.com> wrote:

Christoph Becker

9 years ago
On 02.09.2016 at 17:24, Davey Shafik wrote:
> That would be why I thought it hadn't been missed! > > Thanks Scott (and Christoph :)
And Thomas: <http://php.net/manual/en/migration71.deprecated.php#migration71.deprecated.ext-mcrypt> Cheers!

Leigh

9 years ago
On 2 September 2016 at 16:18, Davey Shafik <davey@php.net> wrote:
> I would still be OK adding this in RC2, TBH. I didn't realize it was missed, > and it's something we _need_ to do. > > - Davey
Actually, my apologies. I appear to have been living in the future and was expecting mcrypt to have been removed this release. Sorry! :)