Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79585
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5489BA91.30503@cubiclesoft.com>
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>
	<5489BA91.30503@cubiclesoft.com>
Date: Fri, 12 Dec 2014 15:29:27 +1100
Message-ID: <CAEZPtU5aR+3wPocam+MRKX5Ja02Ks+hNFbyQPK7hij1UgCV0Eg@mail.gmail.com>
To: Thomas Hruska <thruska@cubiclesoft.com>
Cc: Derick Rethans <derick@php.net>, Andrea Faulds <ajf@ajf.me>, Remi Collet <remi@fedoraproject.org>, 
	PHP Development <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)

hi,

On Fri, Dec 12, 2014 at 2:38 AM, Thomas Hruska <thruska@cubiclesoft.com> wr=
ote:
> On 12/11/2014 3:10 AM, Derick Rethans 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. Wou=
ld 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.
>>
>> cheers,
>> Derick
>
>
> To date, there still isn't a way to access CryptGenRandom() from userland
> without an extension.  Access to that Windows function depends on an
> extension to expose php_win32_get_random_bytes() to userland.
> mcrypt_create_iv() and openssl_random_pseudo_bytes() are the two userland
> functions that do that and mcrypt is compiled into the Windows builds by
> default.  There's nothing in core for getting entropy in userland on Wind=
ows
> despite the fact that two extensions use a function already in the core.
>
> If mcrypt is removed and no suitable replacement function for
> mcrypt_create_iv() is put in place on Windows, the user will be forced to
> load a library that may not even get used.  This is possible because
> openssl_random_pseudo_bytes() does not actually depend on OpenSSL under
> Windows as it calls the php_win32_get_random_bytes() function instead - b=
ut
> the 1MB OpenSSL library will get loaded anyway.
>
> php_win32_get_random_bytes() should be consistently accessible on Windows
> via an ext/standard userland function that gets random bytes of data.  Ot=
her
> than mcrypt_create_iv(), I don't care about the rest of mcrypt.

For the record, when I applied these changes I did not want to create
new APIs only for Windows. The key point is to have portability first
for the existing functions.

--=20
Pierre

@pierrejoye | http://www.libgd.org