On 09/27/2016 04:19 PM, Michael Paquier wrote:
> On Tue, Sep 27, 2016 at 9:01 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> * A source of random values. This currently uses PostmasterRandom()
>> similarly to how the MD5 salt is generated, in the server, but plain old
>> random() in the client. If built with OpenSSL, we should probably use
>> RAND_bytes(). But what if the client is built without OpenSSL? I believe the
>> protocol doesn't require cryptographically strong randomness for the nonces,
>> i.e. it's OK if they're predictable, but they should be different for each
>> session.
>
> And what if we just replace PostmasterRandom()? pgcrypto is a useful
> source of inspiration here. If the server is built with OpenSSL we use
> RAND_bytes all the time. If not, let's use /dev/urandom. If urandom is
> not there, we fallback to /dev/random. For WIN32, there is
> CryptGenRandom(). This could just be done as an independent patch with
> a routine in src/common/ for example to allow both frontend and
> backend to use it.
Yeah, if built with OpenSSL, we probably should just always use
RAND_bytes(). Without OpenSSL, we have to think a bit harder.
The server-side code in the patch is probably good enough. After all, we
use the same mechanism for the MD5 salt today.
The libpq-side is not. Just calling random() won't do. We haven't needed
for random numbers in libpq before, but now we do. Is the pgcrypto
solution portable enough that we can use it in libpq?
> Do you think that this is a requirement for this
> patch? I think not really for the first shot.
We need something for libpq. We can't just call random(), as that's not
random unless you also do srandom(), and we don't want to do that
because the application might have a different idea of what the seed
should be.
- Heikki