Of the use of unpredictableSeed

[Jonathan M Davis via Digitalmars-d]

On Monday, March 06, 2017 22:04:44 Nick Sabalausky  via Digitalmars-d wrote:
> On 03/06/2017 05:19 PM, sarn wrote:
> > On Monday, 6 March 2017 at 10:12:09 UTC, Shachar Shemesh wrote:
> >> Excuse me if I'm asking a trivial question. Why not just seed it from
> >> /dev/urandom? (or equivalent on non-Linux platforms. I know at least
> >> Windows has an equivalent).
> >>
> >> Shachar
> >
> > One reason is that /dev/urandom isn't always available, e.g., in a
> > chroot.  Sure, these are corner cases, but it's annoying when stuff like
> > this doesn't "just work".
>
> I don't claim to be any sort of linux expert or anything, but doesn't
> chroot have a reputation for being a bit of a finicky, leaky abstraction
> anyway? I haven't really used them, but that's been my understanding...?

If you want a fully secure chroot, then what you really want is BSD jails or
Solaris zones. chroots are indeed too leaky to be secure. But secure
container-ization doesn't really matter here, since a D program using D's
standard number generator should work regardless of where it's running. So,
it's a question of whether we're guaranteed to get at /dev/urandom or not,
and if not, how reasonable it is to require that it be accessible for the
program to run. There _are_ programs that require access to /dev, and /dev
is _usually_ available.

Regardless, if there is no guarantee that /dev/urandom (or whatever system
resource for getting randomness is) is going to be accessible, and we want
to use it, then we either have to require that it be accessible and error
out if it isn't, or we have to have a backup if accessing it fails. Ideally,
you'd be able to just use /dev/urandom and not worry about it, but I don't
know how common it is for /dev/urandom to be unavailable or how reasonable
it is to require that it be available.

In general though, using /dev/urandom to seed the pseudo-random number
generator seems like a good plan.

- Jonathan M Davis