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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29542 in the body.
You can then email your comments to 29542 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Leo Famulari <leo <at> famulari.name>
To: guix-patches <at> gnu.org
Subject: rng-tools: New upstream location, new releases
Date: Sat, 2 Dec 2017 19:31:26 -0500

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

Here is a patch to switch the upstream source of rng-tools and update it
to 6.1.

The change was announced on the rng-tools wiki:

https://sourceforge.net/p/gkernel/wiki/Home/

What do you think?

[0001-gnu-rng-tools-Update-to-6.1.patch (text/plain, attachment)]

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

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

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: leo <at> famulari.name, 29542 <at> debbugs.gnu.org
Subject: Re: [bug#29542] rng-tools: New upstream location, new releases
Date: Sun, 3 Dec 2017 20:49:09 +0100

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

Leo,

Leo Famulari wrote on 03/12/17 at 01:31:
> What do you think?

Hm. Looks legit, no?

> From 779b3b9f3532190592d7f85921829f6691947c46 Mon Sep 17 00:00:00 2001
> From: Leo Famulari <leo <at> famulari.name>
> Date: Sat, 2 Dec 2017 18:08:21 -0500
> Subject: [PATCH] gnu: rng-tools: Update to 6.1.
> 
> Rng-tools development appears to have moved to GitHub [0]:
> 
> "NOTE: The rng-tools project hasn't seen updates in some time, but is
> still in active use. To facilitate ongoing development, the rng-tools
> project is moved to here:
> https://github.com/nhorman/rng-tools"
> 
> [0]
> https://sourceforge.net/p/gkernel/wiki/Home/
> 
> * gnu/packages/linux.scm (rng-tools): Update to 6.1.
> [source]: Use new upstream URL.
> [arguments]: Add a 'bootstrap' phase.
> [native-inputs]: Add autoconf, automake, and pkg-config.
> [inputs]: Add curl, libxml2, sysfsutils, and curl.

s/curl/openssl/

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.

> ---
>  gnu/packages/linux.scm | 25 +++++++++++++++++++++----
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
> index 995864f33..d1f9f5902 100644
> --- a/gnu/packages/linux.scm
> +++ b/gnu/packages/linux.scm
> @@ -57,6 +57,7 @@
>    #:use-module (gnu packages calendar)
>    #:use-module (gnu packages check)
>    #:use-module (gnu packages crypto)
> +  #:use-module (gnu packages curl)
>    #:use-module (gnu packages compression)
>    #:use-module (gnu packages databases)
>    #:use-module (gnu packages datastructures)
> @@ -3489,16 +3490,32 @@ The following service daemons are also provided:
>  (define-public rng-tools
>    (package
>      (name "rng-tools")
> -    (version "5")
> +    (version "6.1")
>      (source (origin
>                (method url-fetch)
>                (uri (string-append
> -                "http://downloads.sourceforge.net/sourceforge/gkernel/"
> -                "rng-tools-" version ".tar.gz"))
> +                     "https://github.com/nhorman/rng-tools/archive/v"
> +                     version ".tar.gz"))

This is still missing a ‘file-name’.

The rest looks & builds nicely.

Thanks!

T G-R

[0]:
https://github.com/nhorman/rng-tools/commit/aefe862e187a1ef608f9826b2b4a5bbabd5e9945

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

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

From: Leo Famulari <leo <at> famulari.name>
To: 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: Mon, 4 Dec 2017 13:45:58 -0500

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

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?

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

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)]

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

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: leo <at> famulari.name
Cc: 29542 <at> debbugs.gnu.org
Subject: Re: [bug#29542] rng-tools: New upstream location, new releases
Date: Wed, 6 Dec 2017 03:33:43 +0100

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

Leo,

Leo Famulari wrote on 04/12/17 at 19:45:
> 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 :)

Indeed, at least a signature would have been nice... :-/

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

Oh. If this is going to end up as a dependency on certain systems, I
certainly agree that changes things! Somebody using it for crypto is
unlikely to be simulating Monte Carlos, and one presumes vice versa.

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

Yeah, when we're inundated with e-mails. Sounds good to me!

Kind regards,

T G-R

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

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

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: leo <at> famulari.name, 29542 <at> debbugs.gnu.org
Subject: Re: [bug#29542] rng-tools: New upstream location, new releases
Date: Wed, 6 Dec 2017 03:38:24 +0100

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

Tobias Geerinckx-Rice wrote on 03/12/17 at 20:49:
> Hm. Looks legit, no?

By the way, I take this back. I could be swayed either way.

Kind regards,

T G-R

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

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

From: Leo Famulari <leo <at> famulari.name>
To: 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, 6 Dec 2017 13:07:42 -0500

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

On Mon, Dec 04, 2017 at 01:45:58PM -0500, Leo Famulari wrote:
> 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 dug around a bit.

Fedora uses Neil Horman's fork from GitHub (what this patch changes our
source to):

https://src.fedoraproject.org/cgit/rpms/rng-tools.git/tree/rng-tools.spec?id=2aa45beb753b7401fedcbfa3ccd0a4b005510f56#n10

CentOS fetches from SourceForge with patches by Neil Horman:

https://centos.pkgs.org/7/centos-x86_64/rng-tools-5-11.el7.x86_64.rpm.html

Debian uses their own fork that hasn't been touched in 6 years:

https://anonscm.debian.org/cgit/users/hmh/rng-tools.git/tree/debian/control?id=0235fcf189220aeecc657295b7d3fdd752d3254e

Arch fetches from the old SourceForge project:

https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/rng-tools&id=03d210e8ba320849fd19352174a1b082f4ab2b4f#n10

I don't know how to find package sources on SUSE's web page.

So, I'm confident this source is okay. But after more reading, I don't
think we'll need to use rngd after all.

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

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

From: Leo Famulari <leo <at> famulari.name>
To: 29542-done <at> debbugs.gnu.org
Subject: Re: [bug#29542] rng-tools: New upstream location, new releases
Date: Wed, 20 Dec 2017 03:55:47 -0500

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

On Wed, Dec 06, 2017 at 12:11:36AM +0100, Marius Bakke wrote:
> Leo Famulari <leo <at> famulari.name> writes:
> > 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 ;)

I pushed the update without the NIST beacon support as
8bc6956bbd28b749538d113a214a63a93039537f.

[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.