From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Support getrandom() for pg_strong_random() source |
Date: | 2025-09-29 22:15:37 |
Message-ID: | CAOYmi+mYXKKgGat6+pip-WD=SGFqjXtw3O4b-YR7mBRC0VsiBw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 23, 2025 at 1:41 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-09-29 23:39:56 | Re: [PATCH] Add tests for Bitmapset |
Previous Message | David Christensen | 2025-09-29 21:13:11 | Re: [PATCH] GROUP BY ALL |