VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
tmraz at redhat.com
Fri Jun 7 08:45:59 UTC 2019
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
> 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
No matter how far down the wrong road you've gone, turn back.
[You'll know whether the road is wrong if you carefully listen to your
More information about the openssl-project