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:
- 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.
- 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.
- It'd be nice for superusers (only) to be able to switch
pg_strong_random at runtime, too, for the reasons Michael mentioned
upthread.
- 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?
Thanks,
--Jacob
