Hi Yasuo! On 06.07.2016 at 03:51, Yasuo Ohgaki wrote: > > On Wed, Jul 6, 2016 at 12:37 AM, Christoph Becker <cmbecke...@gmx.de> wrote: >> On 05.07.2016 at 16:32, Leigh wrote: >> >>> On 5 July 2016 at 04:02, Pierre Joye <pierre....@gmail.com> wrote: >>>> We can argue about the provided pnrng being CS but it is not php's job to >>>> decide. >>> >>> I think we need to drop the concerns about exposing "RNG state". >>> >>> A reminder of what php_random_bytes looks at (in order): >>> * CryptGenRandom on Windows >>> * arc4random_buf on modern BSD (where ChaCha20 is used) >>> * Linux getrandom(2) syscall where available >>> * /dev/urandom where available >>> * Throws an exception if it cannot access one of the above >> >> Would that imply that in this latter case sessions couldn't be used >> anymore? What would be the fallback in that case? From a quick glance >> at the current PR there appears to be none! > > It relies on php_random_bytes() defined in ext/standard/random.c > Current PHP does not build without decent PRNG. The patch uses > php_random_bytes() simply.
Yes, I am aware that the patch uses php_random_bytes(), but what happens when it fails, in which case php_session_create_id() returns null[1]? Would it be impossible to use a session in this case? [1] <https://github.com/php/php-src/pull/1850/files#diff-52eb9eb7f9d5d9125fbb1337a6541c06R315> -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
