On Tue, Apr 21, 2026 at 03:42:40PM +0200, Alejandro Colomar via Mutt-dev wrote: > Hi Kevin, > > On 2026-04-21T21:20:17+0800, Kevin J. McCarthy wrote: > > On Tue, Apr 21, 2026 at 02:32:54PM +0200, Alejandro Colomar via Mutt-dev > > wrote: > > > On 2026-04-21T12:49:43+0200, Greg KH wrote: > > > > On Tue, Apr 21, 2026 at 06:13:44PM +0800, Kevin J. McCarthy wrote: > > > > > Perhaps, as Greg KH suggested we could try checking for getrandom(), > > > > > and > > > > > then arc4random_buf(), and if both are missing I guess fall back to > > > > > what > > > > > we have now? > > > > > > > > I would recommend that. I would hope that most modern systems have > > > > getrandom() by now. > > > > > > BTW, getentropy(3) --which itself calls getrandom(2)-- was added to both > > > glibc and musl in the same versions as getrandom(2). Should we prefer > > > getentropy(3) or getrandom(2)? getentropy(3) seems to have been > > > standardized by POSIX.1-2024 --which I'll document in the manual page > > > right now--. > > > > One tiny advantage for getrandom(2) is the GRND_NONBLOCK flag. But > > perhaps there isn't a "real" issue there for the request sizes mutt will > > be passing. > > AFAIK, these days getrandom(2) doesn't block except in weird cases at > boot.
And even then, that should not happen anymore on a sane system. > The manual page random(7) needs to be updated, but I need someone expert > in the matter to send and discuss patches. (CC += Mingye) > > BTW, Greg, would you be able to help with that? Nope! :) I would recommend Jason, the random kernel maintainer, for help with that. > > I've already been playing with the code some tonight. This is just a > > WIP below, compiled but not tested. Of course, it would be easy to swap > > to using getentropy() if you and Greg think that's a better idea. > > It makes sense to start with getrandom(2), since as you say, it's easy > to swap to it. Agreed, the path seems sane. thanks, greg k-h
