PRNG unsafe against forking

[Berbe]

Following this link, LibreSSL's PRNG is not safe and can provide the same 'random' bytes when called from a fork, compared to a call in the original program.

[4a6f656c]

This was addressed over a year ago - did you read the full article, particularly the part under the heading "Update (2014-07-16 03:33 UTC): LibreSSL releases fix for fork issue"?

[busterb]

We even integrated the test from this article into the portable build at the time this was raised. Simply configure with the --enable-extratests flag. It is disabled by default because running this one test can easily take longer than building and running the rest of the tests combined (due to it being a somewhat contrived scenario, fork speed, upper PID bounds, etc.). It is called 'pidwraptest'.

Operating systems can also improve and make solving this problem easier as well. Some have made progress in the year since we addressed this, others have not. I'm looking forward to unmasking some of the blacklisted OS arc4random implementations in the future.

[Berbe]

Thanks for your 'kind' words.
In this 'Update' section, have you also noticed the comments against that less-than-ideal solution of yours, that could be bypassed? The author noted your step wes going the right direction, but that is not enough for a library providing such critical mechanism that lie underneath the whole concept of encryption.

Apart from angry reactions stating I did not RTFM, I would prefer having read replies to that part.