RE: [PATCH 0/2] reftable/stack: stop dying on exhausted entropy pool

On January 7, 2025 6:22 PM, brian m. carlson wrote:

On 2025-01-07 at 15:26:58, Patrick Steinhardt wrote:

quoted

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.

The reason I didn't use RAND_pseudo_bytes is because it's been deprecated since
OpenSSL 1.1.0 and RAND_bytes uses a CSPRNG just like RAND_pseudo_bytes as of
that version.  Once it's seeded, it should be able to generate plenty of bytes,
because I believe it uses a CTR-DRBG, which only needs to be reseeded after 2^48
bytes (which is far more than we should be using).

We can full well use RAND_pseudo_bytes, but all operating systems should provide
an appropriate entropy source that can provide 256 bits of entropy on startup.
arc4random will just kill the process if it can't seed itself, so your changes won't
actually prevent dying on a lack of entropy.

I don't want an option that chooses "insecure" bytes.  My preference is that we
require people use a different backend or an up-to-date OpenSSL version that
shouldn't have this problem.  We can use RAND_pseudo_bytes if we really need to
support older versions, but there are also no major operating systems which
require that old of a version (CentOS 7, which is dead, used OpenSSL 1.0.2, and
CentOS 8 uses 1.1.1k), so it's probably not within our support policy to do that.

Note also that if OpenSSL is being used for TLS, a lack of entropy will result in TLS
not working, which means that Git will be randomly broken on that system, which is
not really an experience that we want to encourage, so that should be taken into
account.

Can we get some more information about what version of OpenSSL is being used
and what the system entropy source is?

In my situation, OpenSSL 3.0.11 on ia64. 3.4.1 and 3.0.13 on x86 (x86 works fine
Because OpenSSL uses hardware. On ia64, we end up on PRNGD, which does fail.