In addition to the overhead of a /dev/urandom read(), since my programs run in a chroot() sandbox, there’s the possibility that the file descriptor to /dev/urandom will no longer function—since chroot() is not part of POSIX, there’s no rigorous standard on how chroot() is supposed to behave with a given operating system.
getrandom() is another possible solution, but the problem with getrandom() is that it’s also not part of the POSIX spec, and my program needs to compile in an anally POSIX compliant system: While my programs use chroot() and setgroups(), both of which aren’t part of the POSIX spec, it has a configure time option to disable both chroot() and setgroups() so everything will compile as long as the underlying system follows POSIX.
The reason for this strict compliance with POSIX is because the changes to the C compilers (gcc and clang) between 2022 and 2026 made previous versions of MaraDNS have issues compiling everything, and, indeed, with these C23 changes to C compilers, unpatched djbdns no longer even compiles with a modern compiler. I changed everything to work with the new C23 spec, then I changed the compile flags to compile with a strictly compliant C99 compiler, but to get that to work, I had to make the program strictly POSIX compliant (with the exceptions of chroot() and setgroups()).
This way, should MaraDNS not compile in the future (remember: The post-C23 changes broke a lot of programs that used to compile just fine), it’s a bug with the compiler not following C99 and/or POSIX, and not a bug with MaraDNS.
Hence, my homegrown secure pseudo random number generator, so I can make strong random numbers while remaining POSIX compliant (we seed the PRNG before entering the chroot() sandbox). Of course, /dev/urandom is also not part of POSIX, but it’s on pretty much any modern *NIX, and trying to open /dev/urandom is not going to raise compile-time errors.