4 ms·
The story is even more interesting. OpenSSL did that _and still does it today_. As a result any program that uses the OpenSSL RNG is full of spurious valgrind e
by nullc 10y ago
The story is even more interesting. OpenSSL did that _and still does it today_. As a result any program that uses the OpenSSL RNG is full of spurious valgrind errors (exactly what you want in security critical code...).
It had (and still has) a -DPURIFY flag available at compile time that gets rid of that stupidity, which is still not default. OpenSSL have not changed it, as I understand, because of a concern that there might exist some embedded system somewhere where that is the only useful source of randomness.
A debian developer saw the errors all over the place, wrote a patch to fix it. The patch, unfortunately, went to far and managed to knock out the secure randomness source to. The patch was posted to the OpenSSL list and no one responded "No don't!" or "Have you seen the already existing DPURIFY?"... and the rest is history.
Fedora, at least, adds DPURIFY, but many other distributions do not.
- mikeash 10y agoOh wow, I didn't realize the option was still there, let alone on by default. Madness. The embedded system argument makes no sense to me (understanding that you're just repeating it, not defending it). If there's no other source of randomness then there's no good source of randomness, period, and you're screwed. Better not to even try, then.