Testing

Okay, I was not clear enough.

The function of a PRNG is of course to take a small number of bytes of high entropy and turn
them into a much longer stream of bytes that has much lower entropy per byte. This is
necessary because true high entropy is scarce. So a PRNG solves a "supply and demand" problem.
And of course Linux has both /dev/random and /dev/urandom which allows a choice of how much
entropy you are guaranteed to get.

What I meant was that OpenSSL should have tests where it statistically verifies the quality of
its *entropy input*, not the output.

This is what hardware RNG's do, they run statistical tests on their entropy input to verify
that physical failure of the high entropy phenomenon that is being measured (radioactivity
etc.) does not destroy the device's security claims. Hardware devices need to do this because
the physical entropy source is typically a single point of failure whereas software PRNG's
rely on multiple sources (keyboard strokes, network packet arrival times etc.)

The Debian OpenSSL bug went undetected because OpenSSL apparently  has no test of the entropy
input similar to what hardware RNG's have. I sure that the upstream team carefully verified
the mechanism, but given the subtleness by which the bug was introduced, it warrants extra
precautions for the future.