| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, 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-10-03 01:03:06 |
| Message-ID: | aN8gyqo-bXaBEXaj@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Oct 02, 2025 at 04:16:43PM -0700, Masahiko Sawada wrote:
> Sounds reasonable. But I have one question: in systems that must be
> FIPS compliant, is it okay to generate UUIDs using random numbers from
> non-FIPS compliant sources? If yes, we can use
> pg_random/pg_fast_random() for UUID generation in all cases.
It seems to me that the answer is no, we should not call stuff that is
not FIPS compliant if we want to be able to say that the backend is
fully FIPS compliant (which comes down to using MD5 and to be able to
report the status and fail gracefully AFAIK, something I've spent
quite some time cleaning up in the backend and the frontend with the
hash computation code). This matters a lot for government class and
some large enterprise customers. Jacob or Daniel, please feel free to
correct me here, perhaps I'm missing a bit related to the random
function bits..
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2025-10-03 01:06:06 | Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options |
| Previous Message | Michael Paquier | 2025-10-03 00:42:48 | Re: [PATCH] Add tests for Bitmapset |