3 ms·
Nice. One nit: any sane OS will provide near-perfect randomness from /dev/urandom (by restoring the last RNG state from disk), but you're bound to run into some
by JoachimSchipper 15y ago
Nice. One nit: any sane OS will provide near-perfect randomness from /dev/urandom (by restoring the last RNG state from disk), but you're bound to run into some idiotic Linux distro which doesn't; its fans will claim that you should have used /dev/random. (A quick search turns up https://dev.openwrt.org/ticket/8687 https://dev.openwrt.org/ticket/8687, which suggests that not saving the RNG state may be more common than I'd hoped.)
A one-line comment in "Security requirements", or even an option to read from /dev/random, may be a good idea.
I tried compiling it on OpenBSD; you should probably #include <string.h> in lib/events/events_network.c for memset() as used in FD_ZERO (see OpenBSD select(2)). OpenBSD has no -lrt either, so I just removed that. It compiles and passes a quick localhost test with these changes.
- cperciva 15y agoA one-line comment in "Security requirements", or even an option to read from /dev/random, may be a good idea. Good point. I'm used to FreeBSD, where /dev/urandom and /dev/random are the same device. you should probably #include <string.h> in lib/events/events_network.c for memset() as used in FD_ZERO POSIX says that <sys/select.h> is all you need. OpenBSD has no -lrt either, so I just removed that. POSIX says that -lrt must work (having a librt isn't required, but if you don't have one the compiler must ignore -lrt). Hopefully these will either get fixed in OpenBSD or as patches in ports/security/spiped if someone decides to add spiped to the OpenBSD ports tree.
- tedunangst 15y agoThanks for pointing these things out. We can probably fix it.
- cperciva 15y agoFWIW, Darwin also gets -lrt wrong, so you're not alone with that one. I was actually rather surprised when I found this stipulation.