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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 3221 bytes --]

On 2025-01-07 at 15:26:58, Patrick Steinhardt wrote:
> 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?
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]