Kevin J. McCarthy wrote in
<aeqgaBYoQ7jxtkj6@qinghai>:
|On Thu, Apr 23, 2026 at 10:05:09AM +0200, Greg KH wrote:
|>On Thu, Apr 23, 2026 at 02:10:31PM +0800, Kevin J. McCarthy wrote:
|>> Use getrandom() if available, or else arc4random_buf(). Only fall
|>> back to using the built-in PRNG if those aren't found on the system.
Btw it seems to me mutt_ssl.c and that RAND handling could see an
iteration (no one uses that .rnd file anymore, RAND_egd() is very
very much dead, and all that).
But anyway, if linked against that, one could use RAND_bytes(),
too. Especially with LibreSSL, where it always succeeds (i think
last i looked it abort()ed on failure).
With OpenSSL they went over certain terrible corners, brought in
and dropped RAND_DRBG_set_reseed_defaults() again, now it is
really, really sad, *but*, you know, Kurt Roeckx said
[we do not]
* ASSERT RAND_status() ("Since you always have to check RAND_bytes's
* return value now, RAND_status is mostly useless.",
* [email protected]), so we have not that many options
* on what to do. Since OSs will try hard to serve, a simple sleep
* may be it, so do that */
Ie we now sleep 250 millies if RAND_bytes() fails (not 200 because
some 20 years ago certain kernels busy looped to satisfy such
sleeps, if i got that right), anticipating that reseeding will
succeed with the next iteration, under the hood, for sure.
(I offer RAND_bytes() only as an option.)
Configuring the RAND with OpenSSL 3.0.0 and above is a horror trip
(and likely not doable at all with the CRNG behind RAND_bytes(),
but i stopped reading that, really. In my opinion it is grazy,
what they do .. especially given that certain jitter "random
daemons" generate thousands of bits of entropy in a fraction of
a second, which then serves them as they succeed to reseed).
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
