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 general, I think it's a good approach.

Currently, the urandom-seed-service seems to non-deterministically but
typically start after the udev-service, so that /dev/hwrng is always set
up by udev before the urandom-seed-service tries to use it.

With these patches, that's not the case. This breaks the hwrng seeding
feature added in 9a56cf2b5b (services: urandom-seed: Try using a HWRNG
to seed the Linux CRNG at boot).

I'll try rearranging the service dependency graph.

> > Leo Famulari <leo@famulari.name> skribis:
> > In practice, I'm not sure if it matters. I'd appreciate if GuixSD users
> > could check /var/log/messages for warnings like this one and report
> > them:
> >
> > random: application: uninitialized urandom read (16 bytes read) 
> 
> I don’t have any of these.  I guess this is most likely to happen when
> running ‘ssh-keygen’ on startup, which isn’t the case on my machine.

Watching a fresh system boot repeatedly, I noticed that the host keys
always seem to be generated immediately after Linux reports "random:
crng init done".

To me, this suggests that OpenSSH is using the getrandom() syscall. If
so, any GuixSD host keys created with glibc >= 2.25 and OpenSSH >= 7.2
should be unpredictable. But I'm not sure if that's what's happening or
not.

> +(define (user-processes-shepherd-service requirements)
> +  "Return the 'user-processes' Shepherd service with dependencies on
> +REQUIREMENTS (a list of service names).
> +
> +This is a synchronization point used to make sure user processes and daemons
> +get started only after crucial initial services have been started---file
> +system mounts, etc.  This is similar to 'target' in systemd."

To clarify, user-processes may be similar to the sysinit target in
systemd. Systemd targets are sort of like run-levels, and there are
several of them, such as the multi-user target, the graphical target,
etc.