Re: Move OpenSSL random under USE_OPENSSL_RANDOM - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Move OpenSSL random under USE_OPENSSL_RANDOM
Date
Msg-id 20200826075659.GI2017@paquier.xyz
Whole thread Raw
In response to Move OpenSSL random under USE_OPENSSL_RANDOM  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Move OpenSSL random under USE_OPENSSL_RANDOM
List pgsql-hackers
On Tue, Aug 25, 2020 at 03:52:14PM +0200, Daniel Gustafsson wrote:
> The USE_OPENSSL_RANDOM macro is defined when OpenSSL is used as a randomness
> provider, but the implementation of strong randomness is guarded by USE_OPENSSL
> in most places.  This is technically the same thing today, but it seems
> hygienic to use the appropriate macro in case we ever want to allow OS
> randomness together with OpenSSL or something similar (or just make git grep
> easier which is my itch to scratch with this).

@@ -24,7 +24,7 @@
 #include <unistd.h>
 #include <sys/time.h>

-#ifdef USE_OPENSSL
+#ifdef USE_OPENSSL_RANDOM
 #include <openssl/rand.h>
 #endif
I agree that this makes the header declarations more consistent with
WIN32.

> The attached moves all invocations under the correct guards.  RAND_poll() in
> fork_process.c needs to happen for both OpenSSL and OpenSSL random, thus the
> check for both.

Yeah, it could be possible that somebody still calls RAND_bytes() or
similar without going through pg_strong_random(), so we still need to
use USE_OPENSSL after forking.  Per this argument, I am not sure I see
the point of the change in fork_process.c as it seems to me that
USE_OPENSSL_RANDOM should only be tied to pg_strong_random.c, and
you'd still get a compilation failure if trying to use
USE_OPENSSL_RANDOM without --with-openssl.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: Implement UNLOGGED clause for COPY FROM
Next
From: Andy Fan
Date:
Subject: Re: Hybrid Hash/Nested Loop joins and caching results from subplans