GNU bug report logs - #29542
rng-tools: New upstream location, new releases

Previous Next

Full log

Message #14 received at 29542 <at> debbugs.gnu.org (full text, mbox):

From: Marius Bakke <mbakke <at> fastmail.com>
To: Leo Famulari <leo <at> famulari.name>, Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 29542 <at> debbugs.gnu.org
Subject: Re: [bug#29542] rng-tools: New upstream location, new releases
Date: Wed, 06 Dec 2017 00:11:36 +0100

[Message part 1 (text/plain, inline)]

Leo Famulari <leo <at> famulari.name> writes:

> 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?

That sounds good to me.  I prefer my entropy sources lightweight ;)

FWIW if you control the hypervisor, you can send something along the
lines of:

qemu -device virtio-rng-pci,bus=pci.0,addr=0x1e,max-bytes=1024,period=1000

to feed the guest with entropy from the host through virtio, up to 1kB/s.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.