On Sun, Dec 03, 2017 at 08:49:09PM +0100, Tobias Geerinckx-Rice wrote:
> Hm. Looks legit, no?

I think so but one can never be sure :)

> I took a look at the recent commit[0] that added most of these:
> 
>   “NIST has a randomness beacon available here:
>   https://www.nist.gov/programs-projects/nist-randomness-beacon
> 
>   It generates entropy at a rate of 512 bits per minute.  Its sent in
>   cleartext over the internet, making it unsuitable for cryptographic
>   function, it is useful in the generation of entropy for things like
>   monte carlo tests or other uses where shared pools of entropy might be
>   useful.  As such, lets add the NIST beacon as an entropy source, but
>   disable it by default so users have to know to keep it enabled.”
> 
> Neat! :-)
> 
> I'd be remiss if I didn't point out that it adds 166.3 MiB to the
> closure, though. On the one hand, that 's a 240% increase in closure
> size for a feature that's ‘disabled by default’ (but read on).
> 
> On the other hand, this is a leaf package only installed by users who
> want it, and I don't like removing features without better reason. I
> also had to add ‘--without-nistbeacon’ to #:configure-flags so it's not
> *that* disabled by default...
> 
> I'm in mild favour of keeping it, but suggest we add a comment above
> those three inputs to point those hacking the recipe in the right direction.

Thanks for digging in here.

I started looking at this package because I'm interested in improving
the situation with the Linux RNG for virtualized GuixSD. Rng-tool's rngd
seems to have a part to play here. I think it would be better to keep the
closure small since it could potentially end up deployed widely.

How about we disable the NIST beacon support for now, and add
'rng-tools-minimal' later if the feature is requested?