On Mon, Aug 17, 2020 at 12:47:40PM +0100, David Brownlee wrote: > On Sun, 16 Aug 2020 at 08:13, Martin Husemann <mar...@duskware.de> wrote: > > > > Hi Nia, > > > > I think you are mixing a few issues here into one discussion - which might > > make sense from a user perspective, but does not help us to get forward. > > I think that the other issues provide important context. > > NetBSD's underlying implementation has a fundamental difference in > blocking entropy behaviour - the specification matches in terms of "an > implementation *may* block... ", but real world use will have some > NetBSD boxes block indefinitely until user intervention, whereas other > systems would not. > > Obviously there is no perfect choice, as other different systems have > made different API behaviour choices, and in general have a less > sophisticated approach to entropy usage, and NetBSD itself has to > cater for boxes with and without hardware entropy. > > However a getentropy() where the *effective* behaviour from a user > perspective matched Linux and the other BSDs but not Solaris would > seem to be a reasonable option. As the Linux random(7) manpage even > suggests "The getentropy(3) function provides a slightly more portable > interface on top of getrandom(2)" > > David
Mm, the indefinite blocking case feels like it should actually be a "return error" case instead. If the user needs to intervene it's better to provide them with feedback instead of waiting for something that isn't going to happen. I do have /dev/random symlinked to /dev/urandom on most of my NetBSD installs due to prior issues (and running 9.0). Riastradh has said he'll investigate rkv1crypto not working in 9_STABLE and pull up the securelevel change, which will allow me to stop doing that. My concern is less for the behaviour of my own systems and more that the behaviour of the underlying implementation is too surprising for apparently portable code.
