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
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_DEPRECATEDpatch 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
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_DEPRECATEDpatch 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.comYou 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?
-
Email internals@lists.php.net to measure reaction to your intended
proposal. -
Get wiki RFC karma
Already had that.
3. Create the RFC
Yes, obviously, I did that. :)
- 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.
- 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?
- 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/
Scott Arciszewski wrote on 22/03/2016 18:09:
- 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]
On Tue, Mar 22, 2016 at 7:09 PM, Scott Arciszewski scott@paragonie.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_DEPRECATEDpatch 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.comYou 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.huLet's go line by line, then?
Email internals@lists.php.net to measure reaction to your intended
proposal.Get wiki RFC karma
Already had that.
3. Create the RFCYes, obviously, I did that. :)
- 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.
- 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.
- 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
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_DEPRECATEDpatch 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
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_DEPRECATEDpatch 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/
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
No objections here.
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
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.
Hi Scott!
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_DEPRECATEDpatch written soon.
Any news here? PHP 7.1.0beta1 has been scheduled for July 19th, which
is feature freeze.
--
Christoph M. Becker
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_DEPRECATEDpatch written soon.
As we're now at RC1, I assume it is too late to push forward with this?
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
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_DEPRECATEDpatch written soon.As we're now at RC1, I assume it is too late to push forward with this?
I thought someone beat me to it?
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com
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
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_DEPRECATEDpatch written soon.As we're now at RC1, I assume it is too late to push forward with this?
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:
I thought someone beat me to it?
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comI 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 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_DEPRECATEDpatch written soon.As we're now at RC1, I assume it is too late to push forward with this?
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:
https://github.com/php/php-src/pull/1996
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comOn Fri, Sep 2, 2016 at 11:18 AM, Scott Arciszewski scott@paragonie.com
wrote:I thought someone beat me to it?
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comI 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 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_DEPRECATEDpatch written soon.As we're now at RC1, I assume it is too late to push forward with this?
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!
- Davey
On Fri, Sep 2, 2016 at 8:19 AM, Scott Arciszewski scott@paragonie.com
wrote:https://github.com/php/php-src/pull/1996
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comOn Fri, Sep 2, 2016 at 11:18 AM, Scott Arciszewski scott@paragonie.com
wrote:I thought someone beat me to it?
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comI 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 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_DEPRECATEDpatch written soon.As we're now at RC1, I assume it is too late to push forward with this?
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! :)