# libmcrypt: abandonware?

- Thread: https://externals.io/message/79446
- Original archive: https://news-web.php.net/php.internals/79446
- Started by Scott Arciszewski on 2014-12-05T16:17:43+00:00
- Messages: 13
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #79446 — Scott Arciszewski — 2014-12-05T16:17:43+00:00

URL: https://externals.io/message/79446#79446

Hi PHP Internals,

I've been trying to get in contact with the maintainers of libmcrypt, but
every response I've gotten was, "Oh, I haven't been a part of that for
years."

http://sourceforge.net/projects/mcrypt/files/Libmcrypt/

The last update to libmcrypt was in 2007. There are bug fixes in their
issue tracker collecting dust.

Is there anyone who knows what happened to the project?

Is there anyone who still holds the reins to it and can approve/reject an
initiative to take over the project (and move it to github of course) if it
is, in fact, abandoned?

Is there anyone in the internals team who would be more qualified (and
willing) than me to take over the project if it is, in fact, abandoned?
(Re: qualification -- probably all of you. Re: willing -- I dunno, lol)

Regards,
Scott

---

## #79520 — Remi Collet — 2014-12-10T06:33:01+00:00

URL: https://externals.io/message/79446#79520 · In reply to: #79446

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 05/12/2014 17:17, Scott Arciszewski a écrit :
> Hi PHP Internals,
> 
> I've been trying to get in contact with the maintainers of
> libmcrypt, but every response I've gotten was, "Oh, I haven't been
> a part of that for years."
> 
> http://sourceforge.net/projects/mcrypt/files/Libmcrypt/
> 
> The last update to libmcrypt was in 2007. There are bug fixes in
> their issue tracker collecting dust.

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).


Remi.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlSH6R0ACgkQYUppBSnxahiRdQCg6IKC9hfJavD9QE3dXEVc8o4t
H+kAoIWLbVRwS5qfidJi8Yq/F/NQ7vlH
=osvZ
-----END PGP SIGNATURE

---

## #79533 — Andrea Faulds — 2014-12-10T18:31:24+00:00

URL: https://externals.io/message/79446#79533 · In reply to: #79520

Hi!

> 
> 
> 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’s my understanding that ext/mcrypt is quite widely used. Would it not be possible to update the lib to use OpenSSL or something on the backend, so existing applications would not need changing?

Thanks!
--
Andrea Faulds
http://ajf.me/

---

## #79542 — Leigh — 2014-12-10T19:37:36+00:00

URL: https://externals.io/message/79446#79542 · In reply to: #79533

>
> It’s my understanding that ext/mcrypt is quite widely used. Would it not be possible to update the lib to use OpenSSL or something on the backend, so existing applications would not need changing?
>

Focusing on the "or something". What are our options outside of OpenSSL?

We could probably cover all of the features of mcrypt by compiling our
own library from a selection of proven public domain or GPL sources if
there is nothing that fits the bill exactly. That would give us the
flexibility to pick the features we want.

I wouldn't object to something a little more current in PHP 7 with an
mcrypt polyfill.

Crypto is a touchy subject though, so what are our options?

---

## #79555 — Pierre Joye — 2014-12-11T06:53:37+00:00

URL: https://externals.io/message/79446#79555 · In reply to: #79520

hi Remi,


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Le 05/12/2014 17:17, Scott Arciszewski a écrit :
> > […]
>
> 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).

I think it is yet another candidate for removal, like imap. It could
became even more critical if some serious flaws will be found in
libmcrypt and never get fixed.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #79556 — Pierre Joye — 2014-12-11T06:54:52+00:00

URL: https://externals.io/message/79446#79556 · In reply to: #79533

> Hi!
>
> > […]
>
> It’s my understanding that ext/mcrypt is quite widely used. Would it not be possible to update the lib to use OpenSSL or something on the backend, so existing applications would not need changing?

I suppose you  mean to replace the functions implementation to use
openssl + some custom codes? As maintaining our own library is not
going to be a good idea :)


-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #79557 — Andrea Faulds — 2014-12-11T07:11:47+00:00

URL: https://externals.io/message/79446#79557 · In reply to: #79556

> 
> 
> > […]
> 
> I suppose you  mean to replace the functions implementation to use
> openssl + some custom codes? As maintaining our own library is not
> going to be a good idea :)

Yes. Essentially it would be a polyfill that uses a crypto library that's actually maintained.

--
Andrea Faulds
http://ajf.me/

---

## #79568 — Derick Rethans — 2014-12-11T10:10:58+00:00

URL: https://externals.io/message/79446#79568 · In reply to: #79533

> > […]
> 
> It’s my understanding that ext/mcrypt is quite widely used. Would 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

---

## #79572 — Leigh — 2014-12-11T13:47:17+00:00

URL: https://externals.io/message/79446#79572 · In reply to: #79446

I need a christmas holiday project, I'll look into a
php7-mcrypt-compat ext backed by OpenSSL then, and see what is
possible and what is not.

I've actually found OpenSSL to be much faster than mcrypt in practice,
so hopefully we can get a performance boost out of this too.

P.S. https://github.com/php/php-src/pull/843 is still open, if someone
else can verify it works for them, that would be helpful.

---

## #79578 — Leigh — 2014-12-11T19:44:53+00:00

URL: https://externals.io/message/79446#79578

>
> 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 Windows
> 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 - but
> 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.  Other
> than mcrypt_create_iv(), I don't care about the rest of mcrypt.
>

I actually think a generic random bytes function outside of any
cryptographic extensions would be a good idea. Even mcrypt seems like
overkill if all you want is random strings.

---

## #79582 — keisial@gmail.com — 2014-12-11T22:29:33+00:00

URL: https://externals.io/message/79446#79582 · In reply to: #79578

> I actually think a generic random bytes function outside of any
> cryptographic extensions would be a good idea. Even mcrypt seems like
> overkill if all you want is random strings.
mcrypt_create_iv should be left as an alias to that function, even if no mcrypt extension is available.

---

## #79585 — Pierre Joye — 2014-12-12T04:29:27+00:00

URL: https://externals.io/message/79446#79585

hi,


> 
> > […]
>
>
> 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 Windows
> 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 - but
> 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.  Other
> 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.

-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #81753 — Pierre Joye — 2015-02-04T00:53:18+00:00

URL: https://externals.io/message/79446#81753 · In reply to: #79568

> 
>
> > […]
>
> 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.

-- 
Pierre

@pierrejoye | http://www.libgd.org