hmm, so I try to use this new `getentropy` system call (please tell me if I'm doing it wrong), result so far is that centos7 does _not_ support it (ok, an ancient glibc). but the other surprise is that alpine (3.10) sometimes returns EAGAIN / ESPIPE -- now, I did this to avoid these error conditions, the man page is pretty clear "EIO/EFAULT/ENOSYS" may be returned... so what am I doing wrong? or should I just go back and read /dev/urandom? :|

standards are so nice, everyone can have their own..

Follow

@hannesm

getrandom(2 should be more portable on Linux and is non-blocking, unlike getentropy(3).

I think the ENOSYS scenario is always possible if you run it on a system too old to even have getrandom(2).

I faced exactly the same challenge in one project that is expected to run on weirdest of unices (old Linux, BSD, Solaris etc) and ended up with rather ugly sequence of fallbacks from getrandom -> OpenSSL -> urandom -> random()

github.com/kravietz/pam_tacplu

Β· Β· 0 Β· 0 Β· 0
Sign in to participate in the conversation
Mastodon πŸ” privacytools.io

Fast, secure and up-to-date instance. PrivacyTools provides knowledge and tools to protect your privacy against global mass surveillance.

Website: privacytools.io
Matrix Chat: chat.privacytools.io
Support us on OpenCollective, many contributions are tax deductible!