Hacker News new | past | comments | ask | show | jobs | submit login

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, 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.




A 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.


Thanks for pointing these things out. We can probably fix it.


FWIW, Darwin also gets -lrt wrong, so you're not alone with that one. I was actually rather surprised when I found this stipulation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: