libmcrypt: abandonware?

9 years ago by Scott Arciszewski — view source

unread

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

9 years ago by Remi Collet — view source

unread

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

9 years ago by Andrea Faulds — view source

unread

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/

9 years ago by Leigh — view source

unread

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?

9 years ago by Pierre Joye — view source

unread

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?

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

9 years ago by Andrea Faulds — view source

unread

On Thu, Dec 11, 2014 at 5:31 AM, Andrea Faulds ajf@ajf.me wrote:

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

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

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

9 years ago by Derick Rethans — view source

unread

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?

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

9 years ago by Pierre Joye — view source

unread

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?

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

9 years ago by Pierre Joye — view source

unread

hi Remi,

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

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

9 years ago by Leigh — view source

unread

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.

9 years ago by Leigh — view source

unread

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.

9 years ago by keisial@gmail.com — view source

unread

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.

9 years ago by Pierre Joye — view source

unread

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?

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