On Mon, Oct 29, 2001 at 04:14:20PM -0500,
Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I believe we discussed this awhile back and decided that it wasn't a
> good idea for Postgres to hack around what is really an OpenSSL bug.
> IIRC, the problem was supposed to be fixed in an upcoming OpenSSL
> release; do you have the latest openssl?
On the particular machine without /dev/random we have openssl-engine-0.9.6a
installed. I looked at the change logs for 0.9.6b and didn't see a change
that would change how it works in this case. I also checked the latest
snapshots for the upcoming 0.9.7 release and things appear to be the same
there. (They will be adding an automatic check for EGD, so that might cover
a larger set of systems.)
The following is from the 0.9.6b documentation:
OpenSSL makes sure that the PRNG state is unique for each thread. On
systems that provide C</dev/urandom>, the randomness device is used
to seed the PRNG transparently. However, on all other systems, the
application is responsible for seeding the PRNG by calling RAND_add(),
L<RAND_egd(3)|RAND_egd(3)>
or L<RAND_load_file(3)|RAND_load_file(3)>.
It looks like they consider not running without seeding the PRNG a feature
and that this isn't something likely to change soon. If you want to override
their decision, I think the simplest solution is to call RAND_seed with
some (not necessarily random) data. That should be pretty portable.
Their FAQ says only 128 bits of entropy are needed to pass the seed check.