Re: lib/56905: getentropy() may return predictable data

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR lib/56905; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Christos Zoulas <christos%zoulas.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: lib/56905: getentropy() may return predictable data
Date: Wed, 29 Jun 2022 23:59:21 +0700

 It is also deliberately intended to not block, that was the whole
 point I think.
 
 As I understand it, the idea is that if you care about security,
 you make sure sufficient entropy is available when the system boots,
 and there isn't an issue with it the way it is now.
 
 If you don't care (that much) about security then you might not do
 that, but you also are very unlikely to care that the initial entropy
 might not be as unpredictable as security conscious people might demand.
 
 But what no-one wants, is processes hanging forever because they're waiting
 on entropy arriving, from somewhere unknown, which no-one cares (or perhaps
 knows) enough about to create.   That's what all the complaints have been
 about.   Note "forever" in the hanging - when there's no initial entropy,
 and nothing providing any, the loop you're proposing adding never terminates.
 
 The plan, which probably has not yet been implemented (as it isn't an ABI
 altering change, and so isn't urgent before the branch) is to have rc.d
 scripts which check (if requested) if entropy is there or not, and if not,
 delay/abort the system startup until some is provided.   If you care about
 security, you'll have that turned on, just in case the entropy source isn't
 available, and needs fixing.   If you don't, you won't, and won't care.
 
 kre