Re: Random MIME boundary needed? (was: Security findings)

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