Re: Support getrandom() for pg_strong_random() source
От | Jacob Champion |
---|---|
Тема | Re: Support getrandom() for pg_strong_random() source |
Дата | |
Msg-id | CAOYmi+mYXKKgGat6+pip-WD=SGFqjXtw3O4b-YR7mBRC0VsiBw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Support getrandom() for pg_strong_random() source (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Support getrandom() for pg_strong_random() source
Re: Support getrandom() for pg_strong_random() source |
Список | pgsql-hackers |
On Tue, Sep 23, 2025 at 1:41 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > With these two patches, for example, users can set random_source_type > to 'system' in the configuration file or a connection string in order > to use getrandom() for random data generation for UUID generation even > on openssl-enabled builds: I'm wary of letting unprivileged users switch this implementation. I think our developers should be allowed to treat the user as an adversary when developing features on top of pg_strong_random(), and it doesn't make sense for an adversary to control properties of your CSPRNG. I'm also worried that allowing users to change the FIPS properties of their systems could lead to compliance headaches for some DBAs, but maybe somebody knows a reason why that wouldn't be a concern in practice. But if only a superuser can change this, I'm not sure that it's going to fit your use case anymore. Which probably brings the conversation back to Daniel's note upthread -- is it worth the cost to expose this as a runtime knob? --Jacob
В списке pgsql-hackers по дате отправления: