From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | 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-03 10:35:18 |
Message-ID: | 20201103103518.GC2298@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 03, 2020 at 10:15:48AM +0100, Magnus Hagander wrote:
> On Wed, Aug 26, 2020 at 2:19 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>> That's certainly true. The intention though is to make the code easier to
>> follow (more explicit/discoverable) for anyone trying to implement support for
>
> Is it really a reasonable usecase to use RAND_bytes() outside of both
> pg_stroing_random() *and' outside of the openssl-specific files (like
> be-secure-openssl.c)? Because it would only be those cases that would
> have this case, right?
It does not sound that strange to me to assume if some out-of-core
code makes use of that to fetch a random set of bytes. Now I don't
know of any code doing that. Who knows.
> If anything, perhaps the call to RAND_poll() in fork_process.c should
> actually be a call to a strong_random_initialize() or something which
> would have an implementation in pg_strong_random.c, thereby isolating
> the openssl specific code in there? (And with a void implementation
> without openssl)
I don't think that we have any need to go to such extent just for this
case, as RAND_poll() after forking a process is irrelevant in 1.1.1.
We are still many years away from removing its support though.
No idea if other SSL implementations would require such a thing.
Daniel, what about NSS?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-11-03 10:48:54 | Re: hash_array_extended() needs to pass down collation |
Previous Message | Peter Eisentraut | 2020-11-03 09:47:14 | Re: [PATCH] remove deprecated v8.2 containment operators |