Migration plan from insecure RNG fallback

[sarciszewski]

Where we are today

WordPress uses paragonie/random_compat to polyfill PHP 7's new CSPRNG functions in PHP 5 projects, (on PHP 7 it just used the new functions directly). However, it currently catches the Exception that is thrown when used on an environment in which PHP cannot access the kernel's CSPRNG (usually /dev/urandom). If an exception is caught, it then proceeds with the old way of doing things: #28633

After nearly one year into random_compat, we've only just recently received our first complaint about an Exception being thrown: ​https://github.com/paragonie/random_compat/issues/91

(If you note, the resolution was: "Our host made /dev/urandom available to us".)

Scott's Proposal

Let's transition away from this insecure RNG fallback. Not all at once, of course.

1. Implement a telemetry feature. How many systems will trigger the fallback code in the first place? Is it negligible (i.e. less than 0.0001% of WordPress installs)? Let's call this a 4.5.0 or 4.5.1 feature.
2. If the telemetry identifies *any* systems that cause random_compat to throw an Exception, let's identify common points of failure. Are they all from the same webhost? Same operating system?
3. Get in touch with as many of the hosting providers as possible and help them remedy these issues.
4. Finally, once we've done everything we can, remove the fallback code entirely. Let's call this a 4.6.0 or 5.0.0 feature, for the sake of argument.

(Tagging @dd32 since he's my usual point of contact for these discussions.)

[sarciszewski]

Good-bye, WordPress.

[kirasong]

This was brought up during triage today.

It was mentioned that the most likely resolution could happen when WordPress starts requiring PHP 7+.

Moving to Security component for more visibility.