Out of the blue after a OS update recently, net/phpldapadmin stops working and drops out with the error: mcrypt_create_iv(): Could not gather sufficient random data obviously rooted at /usr/local/www/phpldapadmin/lib/functions.php (184) error (a:5:{i:0;s:70:"E_WARNING: mcrypt_create_iv(): Coul...) /usr/local/www/phpldapadmin/lib/functions.php () app_error_handler (a:5:{i:0;i:2;i:1;s:59:"mcrypt_create_iv(): Could n...) Datei /usr/local/www/phpldapadmin/lib/functions.php (750) Funktion mcrypt_create_iv (a:2:{i:0;i:8;i:1;i:1;}) Datei /usr/local/www/phpldapadmin/lib/ds.php (227) Funktion blowfish_encrypt (a:1:{i:0;s:40:"cn=ldapadmin,dc=ger,dc=foo,...) Datei /usr/local/www/phpldapadmin/lib/ds_ldap.php (276) Funktion setLogin (a:3:{i:0;s:40:"cn=ldapadmin,dc=ger,dc=fo,...) Datei /usr/local/www/phpldapadmin/htdocs/login.php (25) Funktion login (a:3:{i:0;s:40:"cn=ldapadmin,dc=ger,dc=foo,...) Datei /usr/local/www/phpldapadmin/htdocs/cmd.php (59) Funktion include (a:1:{i:0;s:44:"/usr/local/www/phpldapadmin/htdocs/...) Earlier this week, phpldapadmin simply stopped working after I typed in the login credentials. Switching php.ini to php.ini-development prints out some erro in line 750 of /usr/local/www/phpldapadmin/lib/functions.php Operating system is FreeBSD 11.0-CURRENT #10 r286965: Thu Aug 20 18:13:04 CEST 2015 amd64 port is phpldapadmin-1.2.3_7,1 net/phpldapadmin, installed php56.
I'm thinking this is the result of updates to the RNG system, which I know have been taking place recently. Can you determine when this stopped working? In particular, was r285422 relevant? ( https://svnweb.freebsd.org/base?view=revision&sortby=date&revision=285422 ) Given the error is 'Could not gather sufficient random data' it suggests mcrypt_create_iv() is making some peculiar assumptions about how to produce a string of random bytes. On FreeBSD, it generally suffices to read out of /dev/random, which will not block after the system has booted fully. mcrypt functions are burdened with the common misconception that all the world is Linux and suffers equally from its deficiencies in generating random byte streams. Especially the oft repeated mantra about 'read from /dev/urandom'. Firstly, does /dev/urandom exist on your system? It should be a sym-link to /dev/random, like so: [lucid-nonsense]:...www/phpldapadmin/lib:# ls -l /dev/urandom lrwxr-xr-x 1 root wheel 6 Aug 16 06:57 /dev/urandom@ -> random If not, does the following patch help? --- functions.php~ 2014-07-26 11:45:41.000000000 +0100 +++ functions.php 2015-08-20 21:35:11.543610013 +0100 @@ -747,7 +747,7 @@ if (function_exists('mcrypt_module_open') && ! empty($data)) { $td = mcrypt_module_open(MCRYPT_BLOWFISH,'',MCRYPT_MODE_ECB,''); - $iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td),MCRYPT_DEV_URANDOM); + $iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td),MCRYPT_DEV_RANDOM); mcrypt_generic_init($td,substr($secret,0,mcrypt_enc_get_key_size($td)),$iv); $encrypted_data = base64_encode(mcrypt_generic($td,$data)); mcrypt_generic_deinit($td);
I did so as recommended, but the result is the same. I also updated the ports tree and rebuilt net/phpldapadmin via portmaster -f. No success.
(In reply to ohartman from comment #2) I can't reproduce the problem with the latest versions of everything other than testing on a FreeBSD 10.1 machine. The function in question essentially reads some random bytes out of /dev/urandom or /dev/random and it's hard to imagine how changes in PHP would break that, and only that. I suspect this is something specific to your systems, to do with your running head and with something weird happening to your /dev/{random,urandom} devices.
I am seeing the same issue with php55_mcrypt on a 9.3-p21 amd64 system with php5.5.28 on a zts build. It appears to be related to recent updates to php, as this issue was not present until I brought this machine up to current last weekend.
Temporary workaround seems to be to utilize MCRYPT_RAND instead of MCRYPT_DEV_RANDOM
Is this still a problem with the latest php-5.5.30 ?
The problem seems to be solved by now.
Yeah. Looks like it was an error in PHP. I'm going to mark this PR as closed, since it seems to be fixed in upstream PHP.