no suitable CSPRNG 1.3.0

[menkaff]

i'm getting error when upgrade to 1.3.0
Error : There is no suitable CSPRNG installed on your system on random.php file
my desktop ubuntu is PHP 7.0.4 and the Server PHP is 5.6 , i'm using random_compact in laravel 5.1
i can not fix it on Server so downgrade to 1.2.2
but on on my desktop everything is ok :)

[geggleto]

Well in 1.3 the choice was made to not support openssl.
You should look at the release notes for 1.3.x here https://github.com/paragonie/random_compat/releases

There is a workaround provided in the release notes.

[paragonie-scott]

Hi.

Please check the version 1.3.0 release notes. We removed OpenSSL in 1.3.0 due to a preponderance of concerns over its reliability as a secure provider of random data.

While downgrading to 1.2.2 is probably fine, your application would be far more secure if you made sure it could work with 1.3.0 instead. Can I ask:

• What OS are you running?
• Do you have open_basedir enabled?
• Are you running in, e.g. a FreeBSD jail? (If so, you need access to /dev/urandom.)

[menkaff]

actually it is not s VPS or VDS , it is a very limited shared host , i think it is debian , open_basedir is enable and i do not have access /dev/urandom
i'm sorry i forgot to read release notes. and i think removed OpenSSL make it more secure 👍

[paragonie-scott]

Can you contact your shared host and request access to /dev/urandom?

[Miliooo]

Same problem here, imo this should not have been a 1.3 release but a 2.0 release.
Symfony form 2.8 relies on this component and it updated to the 1.3 version.

This worked fine on my test local server, but my hosting server has no access to dev/urandom.
A quick fix is to rely on "paragonie/random_compat": "1.2" in your composer.json file

[GrahamCampbell]

I'm kind of regretting recommending this to be a 1.3 release. It's biting us in the ass on laravel too.

[paragonie-scott]

OK, then, I'm going to do this:

1. Release 1.4 with OpenSSL restored.
2. Release 2.0 without OpenSSL.

Sound like a plan?

[GrahamCampbell]

👍

[paragonie-scott]

The above plan made sense to me, so I executed it. (I had a feeling that v2.0.0 was the most likely outcome when I posted this.)

Sorry for any inconvenience this caused anyone (on a Friday, no less). The solution should be a composer update away.

[Miliooo]

symfony/polyfill-php70 relies on this component. So while doing a composer update it updated to the 1.3 version. I guess it's used for CSRF form tokens. This made every form page return a 500 error.

So I guess that package should be responsible for relying on the 2.0 version with the workaround? Or alternatively updating the symfony requirements check?

I have my own dedicated server, but I find very little information about how to make /dev/urandom readable

[paragonie-scott]

Update to 1.4.0 or if you don't trust OpenSSL (I don't), upgrade to 2.0.0.

[paragonie-scott]

I'm havind my own dedicated server, but I find very little information about how to make /dev/urandom readable

var_dump(ini_get('open_basedir'));

If that's not empty, edit your php.ini file and add :dev at the end of your configuration directive for PHP.

[narfbg]

:/dev, with the slash.

[Miliooo]

Well now I have this problem:
composer/composer#680

If i want to enable open_basedir i have to whitelist a lot of folders. Doesn't feel very secure to me... But I have no clue what I'm doing.

[narfbg]

You're not supposed to enable it just to whitelist /dev/urandom ... it's the other way around - if it is already enabled, it may be what's preventing you from accessing /dev/urandom.

[Miliooo]

if it is already enabled, it may be what's preventing you from accessing /dev/urandom.

@narfbg thanks I fixed it, it was enabled although my php.ini had it commented out. I'm still using directadmin and that has a php configuration page where you can enable or disable open basedir for each domain. I forgot to check that one.

So i commented out the open_basedir setting in my php.ini, disabled it in directadmin, and now i seem to be able to run 1.3 just fine.

[glensc]

why drop openssl completely, isn't it fixed in later php versions? rather compare php version? or do some feature test?

[GrahamCampbell]

why drop openssl completely

[GrahamCampbell]

why drop openssl completely

This was reverted in 1.4.0.

[glensc]

i understand it was reverted, but my question remains unanswered

[paragonie-scott]

@glensc See #96

[glensc]

so, the "not fork() safe" is stronger reason for completely drop instead of just version compare of fixed php versions?

[paragonie-scott]

What fixed versions? This problem is unfixable on any PHP system that uses Apache.

Don't like it being "completely dropped"? Stick with 1.4. Otherwise, join us in 2.x land.

[paragonie-scott]

In case it wasn't obvious, we're maintaining both 1.x and 2.x branches.

2.x has the added benefit of being truer to random_bytes() which never hooks into OpenSSL's RNG.

1.x has greater compatibility.

Use which ever one you prefer.

[glensc]

you keep saying "this problem", but no explanation what that "this problem" is. from #96 i read out "In most versions of PHP, it lies about being secure", but #70014 says it's fixed in 5.6.11, "uses MD5 as a CSPRNG", but from some comments i read out openssl can be compiled as SHA1 there instead.

[paragonie-scott]

This is the problem I'm referring to.

Is there any point to continue this discussion? Use 1.x if you want OpenSSL, use 2.x if you do not.

[glensc]

so this was the answer original question.

my question is not about what version to use (i do not use any version of this library), i'm trying to understand background of decisions in this library.

[AndrewCarterUK]

@glensc - That is a separate security issue also affecting the OpenSSL random bytes function that was fixed in a later PHP version. The other security issue (regarding forking) is a "cant fix/wont fix" from OpenSSL and as a result this function looks to be always be insecure on all versions of PHP.

Edit - It actually looks like the PHP team is creating a patch for this: https://bugs.php.net/bug.php?id=71915

[maltfield]

fyi, rather than allow php access to '/dev/urandom' (which I imagine would have some negative externalities), I just installed the php libsodium pecl extension.

I encountered this issue with phplist v3.3.3 on a CentOS 7 server running apache v2.4.6 with php v5.6.33.

Solution was to run:

yum install php-pecl-libsodium
httpd -t && service httpd restart

See this article for more info:

• https://tech.michaelaltfield.net/2018/08/25/fix-phplist-500-error-due-to-random_compat/