Hi PHP team,
I've opened the vote on https://wiki.php.net/rfc/mcrypt-viking-funeral
which aims to deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1 (i.e.
make it only installable via PECL).
In the interim, I'll be developing a (MIT licensed) decryption-only
userland implementation of the mcrypt ciphers so people can migrate their
code towards something better.
This vote is opened on March 15th, 2016 and will close March 22th at 17:00
UTC.
(Sidenote: Apologies for the brief unannounced hiatus from participating
here.)
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com
Le 15/03/2016 17:11, Scott Arciszewski a écrit :
Hi PHP team,
I've opened the vote on
https://wiki.php.net/rfc/mcrypt-viking-funeral which aims to
deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1 (i.e. make
it only installable via PECL).In the interim, I'll be developing a (MIT licensed)
decryption-only userland implementation of the mcrypt ciphers so
people can migrate their code towards something better.This vote is opened on March 15th, 2016 and will close March 22th
at 17:00 UTC.
+1 from me.
Probably you miss keeping mcrypt extension means:
"PHP becomes upstream for libmcrypt"
So, to all people who wote "no",
please make clear you want to maintain this library.
Remi.
(Sidenote: Apologies for the brief unannounced hiatus from
participating here.)Scott Arciszewski Chief Development Officer Paragon Initiative
Enterprises <https://paragonie.com
Le 15/03/2016 17:11, Scott Arciszewski a écrit :
Hi PHP team,
I've opened the vote on
https://wiki.php.net/rfc/mcrypt-viking-funeral which aims to
deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1 (i.e. make
it only installable via PECL).In the interim, I'll be developing a (MIT licensed)
decryption-only userland implementation of the mcrypt ciphers so
people can migrate their code towards something better.This vote is opened on March 15th, 2016 and will close March 22th
at 17:00 UTC.+1 from me.
Probably you miss keeping mcrypt extension means:
"PHP becomes upstream for libmcrypt"So, to all people who wote "no",
please make clear you want to maintain this library.
+1 here but I wonder why it would be different now than with 7.0 except
introducing a BC in a minor release (7.2)?
I would still vote +1 while it should be removed with 8.0.
Cheers
Pierre
Le 15/03/2016 17:11, Scott Arciszewski a écrit :
Hi PHP team,
I've opened the vote on
https://wiki.php.net/rfc/mcrypt-viking-funeral which aims to
deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1 (i.e. make
it only installable via PECL).In the interim, I'll be developing a (MIT licensed)
decryption-only userland implementation of the mcrypt ciphers so
people can migrate their code towards something better.This vote is opened on March 15th, 2016 and will close March 22th
at 17:00 UTC.+1 from me.
Probably you miss keeping mcrypt extension means:
"PHP becomes upstream for libmcrypt"So, to all people who wote "no",
please make clear you want to maintain this library.+1 here but I wonder why it would be different now than with 7.0 except
introducing a BC in a minor release (7.2)?I would still vote +1 while it should be removed with 8.0.
Cheers
Pierre
It won't be "removed" wholesale, it will be punted to PECL like what
happened to APC with 5.5.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
On Tue, Mar 15, 2016 at 5:11 PM, Scott Arciszewski scott@paragonie.com
wrote:
Hi PHP team,
I've opened the vote on https://wiki.php.net/rfc/mcrypt-viking-funeral
which aims to deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1 (i.e.
make it only installable via PECL).In the interim, I'll be developing a (MIT licensed) decryption-only
userland implementation of the mcrypt ciphers so people can migrate their
code towards something better.This vote is opened on March 15th, 2016 and will close March 22th at 17:00
UTC.(Sidenote: Apologies for the brief unannounced hiatus from participating
here.)Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com
hi,
first some formalities:
please make sure to follow the process stated at
https://wiki.php.net/rfc/voting
New RFCs first should be proposed for discussion and it would require a bit
of vetting before it can be moved to the voting phase.
I can see your thread "mcrypt extermination plan" but I can't find any mail
linking to the rfc page before this one instantly moving it into voting
phase.
I would suggest cancelling the vote and waiting a bit(I would say 2 weeks)
for any discussion/feedback on the rfc itself.
Personally I also don't like going with the minimal one week voting period
as it is too easy for somebody to miss the chance to vote because of
vacation or just a busy week.
I also wanted to mention that some of unsupported ciphers listed under
https://wiki.php.net/rfc/mcrypt-viking-funeral#backward_incompatible_changes
can in fact be supported by openssl as it(openssl) allows the usage of
plugable engines.
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Tue, Mar 15, 2016 at 5:11 PM, Scott Arciszewski scott@paragonie.com
wrote:Hi PHP team,
I've opened the vote on https://wiki.php.net/rfc/mcrypt-viking-funeral
which aims to deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1
(i.e.
make it only installable via PECL).In the interim, I'll be developing a (MIT licensed) decryption-only
userland implementation of the mcrypt ciphers so people can migrate their
code towards something better.This vote is opened on March 15th, 2016 and will close March 22th at 17:00
UTC.(Sidenote: Apologies for the brief unannounced hiatus from participating
here.)Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comhi,
first some formalities:
please make sure to follow the process stated at
https://wiki.php.net/rfc/voting
New RFCs first should be proposed for discussion and it would require a
bit of vetting before it can be moved to the voting phase.
I can see your thread "mcrypt extermination plan" but I can't find any
mail linking to the rfc page before this one instantly moving it into
voting phase.
I would suggest cancelling the vote and waiting a bit(I would say 2 weeks)
for any discussion/feedback on the rfc itself.
Personally I also don't like going with the minimal one week voting period
as it is too easy for somebody to miss the chance to vote because of
vacation or just a busy week.
I also wanted to mention that some of unsupported ciphers listed under
https://wiki.php.net/rfc/mcrypt-viking-funeral#backward_incompatible_changes
can in fact be supported by openssl as it(openssl) allows the usage of
plugable engines.Ferenc Kovács
@Tyr43l - http://tyrael.hu
https://wiki.php.net/rfc/mcrypt-viking-funeral?do=revisions <- already been
under discussion for a while
> I also wanted to mention that some of unsupported ciphers listed under
https://wiki.php.net/rfc/mcrypt-viking-funeral#backward_incompatible_changes
can in fact be supported by openssl as it(openssl) allows the usage of
plugable engines.
Can be supported !== is currently supported out of the box.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
On Tue, Mar 15, 2016 at 6:13 PM, Scott Arciszewski scott@paragonie.com
wrote:
On Tue, Mar 15, 2016 at 5:11 PM, Scott Arciszewski scott@paragonie.com
wrote:Hi PHP team,
I've opened the vote on https://wiki.php.net/rfc/mcrypt-viking-funeral
which aims to deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1
(i.e.
make it only installable via PECL).In the interim, I'll be developing a (MIT licensed) decryption-only
userland implementation of the mcrypt ciphers so people can migrate their
code towards something better.This vote is opened on March 15th, 2016 and will close March 22th at
17:00
UTC.(Sidenote: Apologies for the brief unannounced hiatus from participating
here.)Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comhi,
first some formalities:
please make sure to follow the process stated at
https://wiki.php.net/rfc/voting
New RFCs first should be proposed for discussion and it would require a
bit of vetting before it can be moved to the voting phase.
I can see your thread "mcrypt extermination plan" but I can't find any
mail linking to the rfc page before this one instantly moving it into
voting phase.
I would suggest cancelling the vote and waiting a bit(I would say 2
weeks) for any discussion/feedback on the rfc itself.
Personally I also don't like going with the minimal one week voting
period as it is too easy for somebody to miss the chance to vote because of
vacation or just a busy week.
I also wanted to mention that some of unsupported ciphers listed under
https://wiki.php.net/rfc/mcrypt-viking-funeral#backward_incompatible_changes
can in fact be supported by openssl as it(openssl) allows the usage of
plugable engines.Ferenc Kovács
@Tyr43l - http://tyrael.huhttps://wiki.php.net/rfc/mcrypt-viking-funeral?do=revisions <- already
been under discussion for a while> I also wanted to mention that some of unsupported ciphers listed
under
https://wiki.php.net/rfc/mcrypt-viking-funeral#backward_incompatible_changes
can in fact be supported by openssl as it(openssl) allows the usage of
plugable engines.Can be supported !== is currently supported out of the box.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
sure, but I still think that it would worth mentioning the possibility
instead of stating that there is no migration path available for those
ciphers.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Tue, Mar 15, 2016 at 6:13 PM, Scott Arciszewski scott@paragonie.com
wrote:On Tue, Mar 15, 2016 at 5:11 PM, Scott Arciszewski scott@paragonie.com
wrote:Hi PHP team,
I've opened the vote on https://wiki.php.net/rfc/mcrypt-viking-funeral
which aims to deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1
(i.e.
make it only installable via PECL).In the interim, I'll be developing a (MIT licensed) decryption-only
userland implementation of the mcrypt ciphers so people can migrate their
code towards something better.This vote is opened on March 15th, 2016 and will close March 22th at
17:00
UTC.(Sidenote: Apologies for the brief unannounced hiatus from participating
here.)Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com
In the RFC:
"Removal from core: The following major/minor version (7.2.0 or 8.0.0)"
and then
"Vote “Yes” to raise an E_DEPRECATED notice in PHP 7.1 when any mcrypt
function is used and to remove the extension from core in 7.1+1."
Which one is it? I feel removing at 7.2 would be too soon. I agree that
the abandonware is a nuisance, but many developers using ext/mcrypt have
no idea of this. Raising an E_DEPRECATED in the next 7.1.x, then
removing in 7.2 is just too soon.
hi,
first some formalities:
please make sure to follow the process stated at
https://wiki.php.net/rfc/voting
New RFCs first should be proposed for discussion and it would require a
bit of vetting before it can be moved to the voting phase.
I can see your thread "mcrypt extermination plan" but I can't find any
mail linking to the rfc page before this one instantly moving it into
voting phase.
I would suggest cancelling the vote and waiting a bit(I would say 2
weeks) for any discussion/feedback on the rfc itself.
Personally I also don't like going with the minimal one week voting
period as it is too easy for somebody to miss the chance to vote because of
vacation or just a busy week.
I also wanted to mention that some of unsupported ciphers listed under
https://wiki.php.net/rfc/mcrypt-viking-funeral#backward_incompatible_changes
can in fact be supported by openssl as it(openssl) allows the usage of
plugable engines.Ferenc Kovács
@Tyr43l - http://tyrael.huhttps://wiki.php.net/rfc/mcrypt-viking-funeral?do=revisions <- already
been under discussion for a while> I also wanted to mention that some of unsupported ciphers listed
under
https://wiki.php.net/rfc/mcrypt-viking-funeral#backward_incompatible_changes
can in fact be supported by openssl as it(openssl) allows the usage of
plugable engines.Can be supported !== is currently supported out of the box.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
sure, but I still think that it would worth mentioning the possibility
instead of stating that there is no migration path available for those
ciphers.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Tue, Mar 15, 2016 at 6:13 PM, Scott Arciszewski scott@paragonie.com
wrote:On Tue, Mar 15, 2016 at 1:09 PM, Ferenc Kovacs tyra3l@gmail.com
wrote:On Tue, Mar 15, 2016 at 5:11 PM, Scott Arciszewski <
scott@paragonie.com>
wrote:Hi PHP team,
I've opened the vote on
https://wiki.php.net/rfc/mcrypt-viking-funeral
which aims to deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1
(i.e.
make it only installable via PECL).In the interim, I'll be developing a (MIT licensed) decryption-only
userland implementation of the mcrypt ciphers so people can migrate
their
code towards something better.This vote is opened on March 15th, 2016 and will close March 22th at
17:00
UTC.(Sidenote: Apologies for the brief unannounced hiatus from
participating
here.)Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.comIn the RFC:
"Removal from core: The following major/minor version (7.2.0 or 8.0.0)"
and then
"Vote “Yes” to raise an
E_DEPRECATEDnotice in PHP 7.1 when any mcrypt
function is used and to remove the extension from core in 7.1+1."Which one is it? I feel removing at 7.2 would be too soon. I agree that
the abandonware is a nuisance, but many developers using ext/mcrypt have
no idea of this. Raising anE_DEPRECATEDin the next 7.1.x, then
removing in 7.2 is just too soon.
I disagree. It's not like we are obliterating the functionality from the
face of the planet, any user requiring mcrypt in 7.2+ can fully aware of
the consequences, install it from PECL. Also, bear in mind that some linux
distros (RHEL) have already dropped mcrypt support.
I've added a section to the wiki page explaining some of the background
information (regarding security) and the motivation for removing the
library:
https://wiki.php.net/rfc/mcrypt-viking-funeral#background_information_regarding_security
This is not a substantive change to the proposal; it is provided for people
reading the RFC that miss parts of the mailing list discussion.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com
Le 15/03/2016 17:11, Scott Arciszewski a écrit :
I've opened the vote on https://wiki.php.net/rfc/mcrypt-viking-funeral
which aims to deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1 (i.e.
make it only installable via PECL).
Hi,
After discussing this RFC at AFUP, we would be +1 to deprecated mcrypt
for PHP 7.1 and to remove it for PHP 8.0
Removing for PHP 7.2 doesn't feel "right" (too soon? and minor versions
should not remove features if it can be avoided).
Thanks for your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/