On Tue, Mar 15, 2016, at 12:18 PM, Ferenc Kovacs wrote: > On Tue, Mar 15, 2016 at 6:13 PM, Scott Arciszewski <sc...@paragonie.com> > wrote: > > > On Tue, Mar 15, 2016 at 1:09 PM, Ferenc Kovacs <tyr...@gmail.com> wrote: > > > >> > >> > >> On Tue, Mar 15, 2016 at 5:11 PM, Scott Arciszewski <sc...@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.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/> > > > > > > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
