Re: Waiting for Randot (or: nia and maya were right and I was wrong)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

Folks, this thread was to discuss a specific proposal about the
getrandom and getentropy C API:

   With these in mind, I propose that we change getrandom(p,n,0) so that
   it does not block -- under the premise that dealing with low entropy
   is a system integration problem, not a problem that it is helpful to
   ask an application to resolve in the heat of the sampling moment.

   Programs can still poll /dev/random (or getrandom(p,n,GRND_RANDOM)),
   if testing for entropy is actually their goal, but the default
   recommended choice for all applications to generate keys, which is
   getrandom(p,n,0), will not.

   I also propose we introduce never-blocking getentropy like nia@
   briefly did last year, as an alias for getrandom(p,n,0) soon to be in
   POSIX (https://www.austingroupbugs.net/view.php?id=1134), under the
   premise that the never-block semantics (from the original in OpenBSD)
   is justified again by treating low entropy as a system integration
   problem.

While I appreciate ideas about how to improve further on the system
integration out of the box, it would also help if you could review the
entropy(7) man page before making suggestions that we already do:

https://man.NetBSD.org/entropy.7

Here's the previous thread where introducing a random.netbsd.org
server came up:

https://mail-index.netbsd.org/tech-crypto/2020/05/13/msg000779.html

I encourage you to read the analysis there before discussing it
further.  That said, I'd also like to focus on the API question in
this thread.