Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96267 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 33796 invoked from network); 6 Oct 2016 10:41:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Oct 2016 10:41:15 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:41892] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 08/CD-23443-94A26F75 for ; Thu, 06 Oct 2016 06:41:15 -0400 Received: (qmail 18591 invoked by uid 89); 6 Oct 2016 10:41:11 -0000 Received: by simscan 1.3.1 ppid: 18584, pid: 18588, t: 0.0919s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 6 Oct 2016 10:41:11 -0000 To: internals@lists.php.net References: Message-ID: <7e9df76d-8327-94ea-ecb3-66f35e03b614@lsces.co.uk> Date: Thu, 6 Oct 2016 11:41:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Intention to move mcrypt to PECL From: lester@lsces.co.uk (Lester Caine) On 06/10/16 11:12, Jakub Zelenka wrote: > I don't think it can be added to PECL as it breaks its licensing rules > (mcrypt is GPL licensed): It is already an established component in PHP and while it's use has been discouraged for a long time, simply switching it off will break a lot of legacy applications. It is not simply a matter of 'changing to a more modern alternative'. If an application has data stored by mcrypt, and it was a popular method of encoding passwords, then any migration path is going to need to provide a method of re-encoding that data while mcrypt is still available. There needs to be a proper migration guide to identify the secondary effects of pulling it although as has been indicated, many distributions will simply build it from PECL and carry on providing it, so the move only really impacts people who build their own installations ... and even there it's a simple exercise to restore anything relegated to the second level of code storage. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk