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 по дате отправления: