bug#29773: urandom-seed-service should run earlier in the boot process

2017-12-22 Thread Ludovic Courtès
Hello, Leo Famulari skribis: > On Thu, Dec 21, 2017 at 10:10:29AM +0100, Ludovic Courtès wrote: >> >> The attached patch does the trick, AFAICS: >> > >> diff --git a/gnu/services/base.scm b/gnu/services/base.scm >> index acc5c33f5..7fc8f6aa7 100644 >> ---

bug#29773: urandom-seed-service should run earlier in the boot process

2017-12-21 Thread Leo Famulari
On Thu, Dec 21, 2017 at 10:10:29AM +0100, Ludovic Courtès wrote: > > The attached patch does the trick, AFAICS: > > diff --git a/gnu/services/base.scm b/gnu/services/base.scm > index acc5c33f5..7fc8f6aa7 100644 > --- a/gnu/services/base.scm > +++ b/gnu/services/base.scm > @@ -529,7 +529,10 @@

bug#29773: urandom-seed-service should run earlier in the boot process

2017-12-21 Thread Ludovic Courtès
Leo Famulari skribis: > On Wed, Dec 20, 2017 at 11:19:36AM +0100, Ludovic Courtès wrote: >> There’s a ‘user-processes’ service that serves a similar purpose. >> >> With the attached patches ‘urandom-seed’ becomes a dependency of >> ‘user-processes’, meaning that daemons &

bug#29773: urandom-seed-service should run earlier in the boot process

2017-12-20 Thread Leo Famulari
On Wed, Dec 20, 2017 at 11:19:36AM +0100, Ludovic Courtès wrote: > There’s a ‘user-processes’ service that serves a similar purpose. > > With the attached patches ‘urandom-seed’ becomes a dependency of > ‘user-processes’, meaning that daemons & co. start after > ‘urandom-seed’. > > WDYT? In

bug#29773: urandom-seed-service should run earlier in the boot process

2017-12-20 Thread Ludovic Courtès
Hello, Leo Famulari skribis: > In some cases, the applications require some random data before any > services are started, during activation. For example, our OpenSSH > service generates its host keys during activation. And even if it > generated host keys during the start

bug#29773: urandom-seed-service should run earlier in the boot process

2017-12-19 Thread Leo Famulari
The urandom-seed-service preserves some of the Linux cryptographic random number generator's (CRNG) pool across reboots so that freshly booted systems have access to unpredictable psuedorandom numbers. It also tries to take advantage of whatever is backing /dev/hwrng. However, the