Hi,
this small patch series fixes the issue reported by Randall [1], where
an exhausted entropy pool can cause us to die when writing a new table
to the reftable stack. I _think_ that this is only an issue with the
OpenSSL backend of `csprng_bytes()`:
- `arc4random_buf()` never returns an error.
- `getrandom()` pulls from "/dev/urandom" by default.
- `getentropy()` seems to block when there is not enough randomness
available.
- `GtlGenRandom()` I cannot really tell.
- The fallback reads from "/dev/urandom", which also returns bytes in
case the entropy pool is drained.
So OpenSSL's `RAND_bytes()` seems to be the only one that returns an
error when the entropy pool is empty. I did wonder whether we even need
to introduce the new flag in the first place, or whether we cannot just
use `RAND_pseudo_bytes()` unconditionally. But I'm a bit uneasy about it
given that OpenSSL has this doc:
RAND_pseudo_bytes() puts num pseudo-random bytes into buf.
Pseudo-random byte sequences generated by RAND_pseudo_bytes() will
be unique if they are of sufficient length, but are not necessarily
unpredictable. They can be used for non-cryptographic purposes and
for certain purposes in cryptographic protocols, but usually not for
key generation etc.
It might be too easy to accidentally rely on `csprng_bytes()` where it
actually requires strong cryptographic data, so I was erring on the side
of caution.
Thanks!
---
Patrick Steinhardt (2):
wrapper: allow generating insecure random bytes
reftable/stack: accept insecure random bytes
builtin/gc.c | 2 +-
reftable/stack.c | 4 ++--
t/helper/test-csprng.c | 2 +-
t/unit-tests/t-reftable-readwrite.c | 6 +++---
wrapper.c | 24 ++++++++++++++----------
wrapper.h | 16 ++++++++++++----
6 files changed, 33 insertions(+), 21 deletions(-)
---
base-commit: b74ff38af58464688b211140b90ec90598d340c6
change-id: 20250107-b4-pks-reftable-csprng-9ed4e8dd83c4
