Re: Move OpenSSL random under USE_OPENSSL_RANDOM
От | Michael Paquier |
---|---|
Тема | Re: Move OpenSSL random under USE_OPENSSL_RANDOM |
Дата | |
Msg-id | 20201103103518.GC2298@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Move OpenSSL random under USE_OPENSSL_RANDOM (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Move OpenSSL random under USE_OPENSSL_RANDOM
|
Список | 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@yesql.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
Вложения
В списке pgsql-hackers по дате отправления: