From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Move OpenSSL random under USE_OPENSSL_RANDOM |
Date: | 2020-11-16 00:20:16 |
Message-ID: | 20201116002016.GA2656@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Nov 15, 2020 at 12:16:56PM -0500, Tom Lane wrote:
> The obvious problem with this is that if !USE_OPENSSL, we will not have
> pulled in openssl's headers.
FWIW, I argued upthread against including this part because it is
useless: if not building with OpenSSL, we'll never have the base to be
able to use RAND_poll().
> However ... all these machines are pointing at line 96, which is not
> that one but the one under "#if defined(USE_OPENSSL)". So I'm not sure
> what to make of that, except that a bit more finesse seems required.
The build scripts of src/tools/msvc/ choose to not use OpenSSL as
strong random source even if building with OpenSSL. The top of the
file only includes openssl/rand.h if using USE_OPENSSL_RANDOM.
Thinking about that afresh, I think that we got that wrong here on
three points:
- If attempting to use OpenSSL on Windows, let's just bite the bullet
and use OpenSSL as random source, using Windows as source only when
not building with OpenSSL.
- Instead of using a call to RAND_poll() that we know will never work,
let's just issue a compilation failure if attempting to use
USE_OPENSSL_RANDOM without USE_OPENSSL.
- rand.h needs to be included under USE_OPENSSL.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
win32-openssl.patch | text/x-diff | 1.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-11-16 00:23:24 | Re: Online verification of checksums |
Previous Message | Jeff Janes | 2020-11-15 23:13:15 | Re: Supporting = operator in gin/gist_trgm_ops |