Re: Support getrandom() for pg_strong_random() source

On Mon, Sep 29, 2025 at 03:15:37PM -0700, Jacob Champion wrote:
> 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.

I'm pretty sure that all cloud vendors would face this dilemma, and
another thing that I suspect it that they would restrict entirely the
access to this GUC.

> 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?

I don't think we should expose that as a runtime-updatable parameter.
Even for UUIDs, I am reading the RFC as "more entropy the better" and
I would choose entropy over performance every single day, because it's
a no brainer if you care about cryptography, especially if this option
enforces which source to use for for *all* code paths that want random
bytes. So there is no deal about performance here, at least IMHO.

Even as a superuser parameter, I'm having cold feet with this
prospect. There are two aspects not discussed on this thread that
could justify a PGC_POSTMASTER:
- Testing, by being able to switch from one source to the other,
providing more coverage with external libraries, useful for the
buildfarm.
- Insurance policy against vendor and library bugs. By switching to a
different source with an existing build, it is possible to redirect
the source of a bug somewhere else. It was also one of the reasons
behind the GUCs that control the SSL protocol versions, where we
wanted to bypass some versions. With TLSv3, this is less an issue
these days, compared to SSLv1/2, still the argument applied when the
SSL protocol GUCs were added.
--
Michael