On Fri, 2019-06-07 at 10:18 +0200, Tomas Mraz wrote: > On Fri, 2019-06-07 at 18:03 +1000, Dr Paul Dale wrote: > > > > Viktor replied: > > > > > I just want to make sure we don't lock ourselves in to a single > > > potentially clumsy solution in the library. Various strategies > > > may be appropriate depending on the platform, and ultimately the > > > cooperation of the system administrator to enable the required > > > mechanisms. > > > > > > Potential additional sources for initial entropy on systems > > > without getrandom(2) might include: > > > > > > RDSEED/RDRAND > > > TPM (or Virtualized TPM which is sometimes better!) > > > RNG state saved across reboots. > > > ... > > > > > > This requires knowledge of various platforms, and potential > > > help from the platform vendors. It might, for example, make > > > sense to delegate initial seeding to systemd on platforms > > > that use systemd, and work with the systemd maintainers to > > > provide a set of sensible entropy sources for initial boot. > > > > > > Exposing a decent RNG to virtual guests and containers is > > > would be another area of focus. > > From the point of view of distribution maintainer of OpenSSL I would > say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT > had > no real problems for us.
And to clarify myself - we have no problem with the DEVRANDOM_WAIT introduction either as the -DDEVRANDOM=/dev/urandom works nicely for us. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]