This is a discussion on Re: RAND_egd() blocking -- despite contract that states otherwise? - Openssl ; Hello Lutz and thank you for your informed response. Unfortunately I don't know exactly which version of prngd was being used because I'm not the first-tier responder for this issue. What I'm doing is preparing a portfolio of information so ...
Hello Lutz and thank you for your informed response.
Unfortunately I don't know exactly which version of prngd was being
used because I'm not the first-tier responder for this issue. What
I'm doing is preparing a portfolio of information so that we can
analyze exactly what may have happened and how we can prevent it in
It is immensely helpful that you have explained the actual behavior of
OpenSSL's EGD reading because it confirms that prngd was likely
behaving unexpectedly on that particular configuration.
In answer to your question about timeouts, given that the reads are
usually on the order of 30-40 bytes. a timeout of a few seconds
(five?) should be sufficient to allow even the most heavily-loaded
system to respond. If prngd isn't responding in that timeframe then
there is probably something else wrong. That said, the specific
timeout value isn't important to me as long as a timeout does occur at
some point so that our process continues and we can issue a reasonable
For what it's worth, I had investigated setting blocking socket
timeout recv/snd options but these don't seem to be supported on some
(all?) platforms for UNIX Domain Sockets.
Our resolution will be the following:
1) Make notations that in situations like this, look for prngd running
on the system and make sure it is the most recent version.
2) Support a way to disable EGD usage for cases where the prngd
interaction is not working reliably, for whatever reason.
3) Incorporate any future OpenSSL EGD updates into our builds.
OpenSSL Project http://www.openssl.org
User Support Mailing List email@example.com
Automated List Manager firstname.lastname@example.org