Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:81661 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71867 invoked from network); 2 Feb 2015 22:16:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Feb 2015 22:16:29 -0000 Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:59581] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F7/B9-25089-837FFC45 for ; Mon, 02 Feb 2015 17:16:25 -0500 Received: by h1123647.serverkompetenz.net (Postfix, from userid 33) id A1C9923D6002; Mon, 2 Feb 2015 23:16:21 +0100 (CET) Received: from 87.159.48.115 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Mon, 2 Feb 2015 23:16:21 +0100 Message-ID: In-Reply-To: References: <2ebcb8f91e4185726e4bf49d5e675c2a.squirrel@webmail.klapt.com> Date: Mon, 2 Feb 2015 23:16:21 +0100 To: "Andrey Andreev" Cc: "Anatol Belski" , "Nikita Popov" , "PHP internals" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions From: anatol.php@belski.net ("Anatol Belski") Hi, On Mon, February 2, 2015 22:39, Andrey Andreev wrote: > Hi, > > > On Mon, Feb 2, 2015 at 9:45 PM, Anatol Belski > wrote: > >> On Mon, February 2, 2015 20:30, Andrey Andreev wrote: >> >>> Oh, forgot one thing ... >>> >>> >>> >>> Mcrypt might be dead, but removing it would be a huge BC break. There >>> was some talk of binding mcrypt_*() functions to ext/openssl - I'd >>> suggest that instead of removal. >>> >> that sounds plausible, but the same one could say about mapping to be >> removed regex to pcre. If anything of that is going to be happening, so >> I >> would welcome another RFC and implementation. >> > > Not quite ... ereg has been deprecated since PHP 5.3, while mcrypt was > never deprecated and is extremely wide-spread in PHP code (that does > encryption) today. > yeah, looking at the openssl you've mentioned, and which was vulnerable to any possible attacks last years, and has fixed those ... Asking myself, how a library which wasn't updated since like eight years does feel :) Can it still provide that really secure encryption? And should one provide something like that as a secure solution? Comparing with regex I meant, one could provide a replacing API. Just where with regex it's more like functionality breach (whereby security as well, as that lib wasn't revisited maybe for much longer than mcrypt), with mcrypt it's a security weakness we would still try to sell for safe. Regards Anatol.