[RFC][VOTE] Deprecate then Remove Mcrypt

> On Mar 16, 2016 12:22 AM, "Remi Collet" <remi@fedoraproject.org> wrote: > > > > 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 >

> 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.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 >> > > > > 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/> > ​ > >