| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Daniel Gustafsson <daniel(at)yesql(dot)se>, 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-07-30 16:13:06 |
| Message-ID: | CAOYmi+khvFu_a4zLDhVanzN3sTV2dHYp31=wxDM_EqgMhqbyZA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 30, 2025 at 4:09 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> The POSIX description of getentropy() says:
>
> "The intended use of this function is to create a seed for other
> pseudo-random number generators."
>
> So using getentropy() for generating the random numbers that are passed
> back to the application code would appear to be the wrong use.
What are the situations in which a stream of numbers would be suitable
for seeding a CSPRNG, but not suitable as output from a CSPRNG?
On Wed, Jul 30, 2025 at 4:10 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
> The point still stands that the number of installations without OpenSSL
> support is approximately zero, so what is the purpose of this patch if
> approximately no one will be able to use it?
Upthread I'd suggested that we put some thought into making it
configurable, with the understanding that we'd need to document
exactly what we think the advantages of the approaches are.
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Bauman | 2025-07-30 16:27:39 | Re: Doc update proposal for the note on log_statement in the runtime config for logging page |
| Previous Message | Tom Lane | 2025-07-30 16:06:31 | Re: Making type Datum be 8 bytes everywhere |