Re: Support getrandom() for pg_strong_random() source - Mailing list pgsql-hackers

On Thu, Oct 9, 2025 at 9:08 AM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> On Tue, Oct 7, 2025 at 1:40 AM Daniel Gustafsson <daniel@yesql.se> wrote:
> > None come to mind, and it seems increasingly likely that designing API which we
> > confidently can document how to use is too complicated.  Maybe it's better to
> > re-focus on just the usecase in the UUID code and leave the API at pg_prng()
> > and pg_strong_random()?  (We already have UUID code in contrib which in some
> > cases use arc4random after all.)
>
> Maybe that would be best. If a second use case does show up in the
> future, we'd be better positioned to pull it out into an API (and we'd
> know how to document it!).
>
> Sawada-san: I feel like I've driven your thread off the rails (off a
> cliff?). Maybe I can try to summarize some of the ideas that seem to
> be emerging, without signing you up for them:

Thank you for summarizing the ideas.

> - We should let superusers switch UUID generation to a faster CSPRNG,
> like getrandom().
> - The UUID switch should be done at a layer above pg_strong_random().
> Maybe just in the UUID code for now, so that we don't choose a bad
> abstraction.

Agreed.

> - It seems important for pg_strong_random() to default to a
> known-FIPS-complaint solution whenever available.
> - Packagers should be able to select a pg_strong_random alternative at
> compile time, since kernel-level randomness can potentially bring
> security improvements in addition to speed, not everyone cares about
> FIPS anyway, and it's conceivable that some distributions might
> provide FIPS-compliant kernel randomness.

Does it mean that we introduce something like pg_fast_random() and
packagers can select it as the random number generation function
instead of pg_strong_random()? Or can packagers select the function
used in pg_strong_random()?

> - It'd be nice for superusers (only) to be able to switch
> pg_strong_random at runtime, too, for the reasons Michael mentioned
> upthread.

+1 . It seems close to the patch I drafted before.

> - We should document the RFC's warning about UUIDs not being
> considered cryptographic secrets.
>
> There is still a question of whether unprivileged users should be able
> to switch the UUID implementation. That seems to hinge, unfortunately,
> on whether or not we think someone could be relying on it for security
> and/or FIPS.
>
> Does that all seem reasonable, and are there pieces I should peel off
> into other threads?

All of these sound reasonable to me. I think we can handle this as two
separate discussions: one for the UUID implementation changes, and
another for the pg_strong_random() modifications (which would cover
both the runtime switching for superusers and the compile-time
alternatives for packagers).

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com