[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#29542] rng-tools: New upstream location, new releases

From: Marius Bakke
Subject: [bug#29542] rng-tools: New upstream location, new releases
Date: Wed, 06 Dec 2017 00:11:36 +0100
User-agent: Notmuch/0.25.2 ( Emacs/25.3.1 (x86_64-pc-linux-gnu)

Leo Famulari <address@hidden> 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:
>>   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.

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]