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

>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?