From: | Olivier PRENANT <ohp(at)pyrenet(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: psql+openssl+uniware7 |
Date: | 2001-06-23 16:49:38 |
Message-ID: | Pine.UW2.4.21.0106231838190.21262-100000@server.pyrenet.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I was afraid you would say that.
As a user of postgresql for many years, one thing I love is that it's
multi-platform.
Unfortunatly, not all platforms have /dev/urandom.
here is part of openssl doc (RAND_add.pod)
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 clearly states that THE APPLICATION (psql) is responsible for seedinf
the PRNG. ISTM, saying it's a bug of openssl when it's IN THE DOC seems a
bit "unnice".
Even openssh (widely used) seeds PRNG itself.
I'm not trying to start a war, I love Postgresql too much for that, but
just say, I'll TRY to come up with a patch.
Regards,
On Fri, 22 Jun 2001, Tom Lane wrote:
> Olivier PRENANT <ohp(at)pyrenet(dot)fr> writes:
> >> Shouldn't this be handled by the OpenSSL configuration?
>
> > Not yet, opensl-0.9.7 will detect egd. Until then, client has to seed
> > prng.
>
> I think we shouldn't patch our code to work around an openssl bug that
> will go away soon anyway.
>
> regards, tom lane
>
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp(at)pyrenet(dot)fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-06-23 17:17:27 | Re: [GENERAL] Multiple Indexing, performance impact |
Previous Message | Peter Eisentraut | 2001-06-23 16:32:17 | Re: [GENERAL] Multiple Indexing, performance impact |