Re: Support getrandom() for pg_strong_random() source

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: Support getrandom() for pg_strong_random() source
Дата
Msg-id 1B62B216-9B2B-42F7-B570-0E5CB4E01932@yesql.se
обсуждение исходный текст
Ответ на Re: Support getrandom() for pg_strong_random() source  (Jacob Champion <jacob.champion@enterprisedb.com>)
Список pgsql-hackers
> On 26 Aug 2025, at 00:38, Jacob Champion <jacob.champion@enterprisedb.com> wrote:
>
> On Mon, Aug 25, 2025 at 3:22 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>>
>> For instance, we could
>> introduce a GUC parameter that lets users specify their preferred
>> random number source. Or the server can automatically select it based
>> on the kernel's FIPS mode (i.e., checking
>> /proc/sys/crypto/fips_enabled).
>
> Interesting idea. (Are there any users reading along who would
> definitely use such a feature?)

I worry about the added complexity this would bring.  It's already quite
complicated to configure postgres, and making an informed decision about which
RNG source to choose for cryptographically strong random won't be easy without
domain knowledge.

Taking a step back and re-reading the thread, this started as a proposal to
improve uuid generation on non-Windows platforms when not using OpenSSL.  While
non-SSL installations will be incredibly rare in production, it will likely be
a bit more common in PG development situations and speeding up test-runs in
such situations has value.  I think this thread has shown merit to the idea of
replacing using /dev/urandom with a more modern API, but after sleeping on it
I'm less convinced that a'la carte CSPRNG configuration has enough upsides to
warrant the risk of users accidentally becoming non-FIPS compliant.

Another related thing to consider, uuid-ossp contrib module use arc4random() in
the non e2fs case.

--
Daniel Gustafsson




В списке pgsql-hackers по дате отправления: