Hi Florian, On Sat, Jun 13, 2026 at 12:04:08PM +0200, Florian Weimer wrote: > > On Wed, 2026-06-03 at 17:12 -0400, Aaron Merey wrote: > >> On Tue, Jun 2, 2026 at 6:47 AM Mark Wielaard <[email protected]> wrote: > >> > + do > >> > + { > >> > + uint64_t r; /* We need at least 64^6 == 2^36 */ > >> > + if (TEMP_FAILURE_RETRY (getrandom (&r, sizeof (r), 0)) != sizeof > >> > (r)) > >> > >> getrandom was introduced in glibc 2.25 (Feb 2017) so it's probably safer if > >> we add a configure check for getrandom or <sys/random.h>. There's one > >> already > >> for reallocarray (glibc 2.26) plus fallbacks if it's missing. > > > > I would hope 9 years is old enough. But yeah. I'll add a "fallback > > getrandom" for systems that don't have it. Meh. > > It can also be blocked by a seccomp filter in a container.
Groan, do people really do that? But yes, my v3 patch has both a compile time and runtime fallback to just reading from /dev/urandom. Hopefully that is enough. Or do you think we also need some other "time based" fallback just in case? Having glibc actually implement mkstempat would be ideal. This was supposed to be a simple oneliner patch, just adding an flag to an open call. But then we got into the rabit hole of replacing the path based file manipulation (which has all kinds of toctou issues) into file descriptor based calls. And it seems glibc doesn't fully provide the needed support, so we ended up implementing our own xmkstempat. Little did I realize that meant making choices like which file characters are "safe" or selecting sources of randomness... Thanks, Mark
