Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81753
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1412111009330.4080@whisky.home.derickrethans.nl>
References: <CAPKwhwsOZiGPkvEtXYCBX3dJP3SJ=PTrwqRtQWVzX3SegK6jsg@mail.gmail.com>
	<5487E91D.6070602@fedoraproject.org>
	<648FEBB3-9D71-4AE3-BFDA-5ED268FC02A7@ajf.me>
	<alpine.DEB.2.11.1412111009330.4080@whisky.home.derickrethans.nl>
Date: Wed, 4 Feb 2015 07:53:18 +0700
Message-ID: <CAEZPtU6sQqOM=is7DDsBDXeGDYk2GjfFqsD+LA5Aiq-imvtEyg@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: Andrea Faulds <ajf@ajf.me>, Remi Collet <remi@fedoraproject.org>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] libmcrypt: abandonware?
From: pierre.php@gmail.com (Pierre Joye)

On Thu, Dec 11, 2014 at 5:10 PM, Derick Rethans <derick@php.net> wrote:
> On Wed, 10 Dec 2014, Andrea Faulds wrote:
>
>> > On 10 Dec 2014, at 06:33, Remi Collet <remi@fedoraproject.org> wrote:
>> >
>> > Having a dead upstream for crypto API is a critical issue :(
>> >
>> > FYI some downstream (ex RHEL) don't even provide this library.
>> > Already too much crypto libraries, and it will be a mess to provide
>> > a dead project in an Enterprise distribution.
>> >
>> > So php/mcrypt also not available.
>> >
>> > But most applications. which use it, usually have alternative, and
>> > make it optional (ex phpMyAdmin 4.3 now even use openssl as first
>> > choice).
>> >
>> > We probably have enough crypto API in PHP, and we probably should
>> > mark this one as deprecated / unmaintained in 5.x, and move it to
>> > PECL (7.x).
>>
>> It=E2=80=99s my understanding that ext/mcrypt is quite widely used. Woul=
d it
>> not be possible to update the lib to use OpenSSL or something on the
>> backend, so existing applications would not need changing?
>
> I think you're going to find this difficult, as the mcrypt
> implementations can have some odd quircks in them. As the "maintainer"
> of this extension I'd say to just drop it in PHP 7. I wouldn't even
> bother trying to make it compile for it.

You won't bother but we should? Wondering why you voted against removing it=
.

--=20
Pierre

@pierrejoye | http://www.libgd.org