| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Support getrandom() for pg_strong_random() source |
| Date: | 2025-07-28 15:29:29 |
| Message-ID: | CAOYmi+nZEVdrPoSOhpovQoE3A4=ALC4a6rvmHRSYKYZy7jSBpQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 28, 2025 at 4:36 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> There has in the past been discussions (at least off-list in hallway tracks)
> about allowing randomness to be chosen separately from underlying factors such
> as OpenSSL support, at the time it didn't seem worth the trouble but that may
> well have changed.
Yeah, especially if other options with similar strength could be much
faster. But the comparison is really going to be OS-dependent [1, 2].
> With OpenSSL 1.1.1 being the baseline we can also make use of the _priv_bytes
> functions to get increased isolation.
Hmm, that's an interesting idea too.
To move this forward a tiny bit: I would be okay with maintaining a
new getentropy() case. (I'm less excited about getrandom() because of
its reduced reach.) And maybe down the line we should discuss choosing
an option at configure time?
--Jacob
[1] https://lwn.net/Articles/983186/
[2] https://dotat.at/@/2024-10-01-getentropy.html
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2025-07-28 16:03:38 | Re: Explicitly enable meson features in CI |
| Previous Message | Robert Haas | 2025-07-28 15:22:49 | Re: Better HINT message for "unexpected data beyond EOF" |