getentropy(2) on OpenBSD
Your text suggests using getentropy(2) on OpenBSD:
On OpenBSD, use getentropy(), which has a similar behavior and predates Linux' syscall.
getentropy(2) is meant to be used only to seed in-process RNGs. The man page for getentropy(2) says:
getentropy() fills a buffer with high-quality entropy, which can be used as input for process-context pseudorandom generators like arc4random(3).
[...]
getentropy() is not intended for regular code; please use the arc4random(3) family of functions instead.
Considering that, it may be more suitable advice to suggest arc4random(3) in the text for OpenBSD in particular. RAND_bytes in OpenBSD's LibreSSL just calls arc4random_buf(3) directly, which suggests that it is completely suitable for cryptographic usage.
Incidentally, FreeBSD has finally changed their implementation away from RC4 to ChaCha20 as well, so it will be a safe bet even on there for versions >= 12.0 (but not the current 11.x series).
/dev/(u)random
The (u)random devices may be tampered with. I don't think there's a realistic threat model, but you may want to make people check the major and minor device numbers before opening /dev/(u)random just in case if they know the target platform.
Possibly you may want to have a distinct return code for /dev/urandom not existing in the example code: If it doesn't exist, there's absolutely nothing the program can do. (Furthermore, just reproducing substantial parts of the code from LibreSSL(-portable) without the copyright notice and license notice may be a violation of copyright/its license.)
getentropy(2) on OpenBSD
Your text suggests using getentropy(2) on OpenBSD:
getentropy(2) is meant to be used only to seed in-process RNGs. The man page for getentropy(2) says:
Considering that, it may be more suitable advice to suggest arc4random(3) in the text for OpenBSD in particular.
RAND_bytesin OpenBSD's LibreSSL just calls arc4random_buf(3) directly, which suggests that it is completely suitable for cryptographic usage.Incidentally, FreeBSD has finally changed their implementation away from RC4 to ChaCha20 as well, so it will be a safe bet even on there for versions >= 12.0 (but not the current 11.x series).
/dev/(u)random
The (u)random devices may be tampered with. I don't think there's a realistic threat model, but you may want to make people check the major and minor device numbers before opening /dev/(u)random just in case if they know the target platform.
Possibly you may want to have a distinct return code for /dev/urandom not existing in the example code: If it doesn't exist, there's absolutely nothing the program can do. (Furthermore, just reproducing substantial parts of the code from LibreSSL(-portable) without the copyright notice and license notice may be a violation of copyright/its license.)