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

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

[Leo Famulari]

[-- Attachment #1.1: Type: text/plain, Size: 196 bytes --]

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?

[-- Attachment #1.2: 0001-gnu-rng-tools-Update-to-6.1.patch --]
[-- Type: text/plain, Size: 2744 bytes --]

From 779b3b9f3532190592d7f85921829f6691947c46 Mon Sep 17 00:00:00 2001
From: Leo Famulari <leo@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.
---
 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"))
               (sha256
                (base32
-                "13h7lc8wl9khhvkr0i3bl5j9bapf8anhqis1lcnwxg1vc2v058b0"))))
+                "00ywsknjpc9jd9kfmz2syk9l0xkiiwyx5qhl5zvhhc69v6682i31"))))
     (build-system gnu-build-system)
+    (arguments
+     `(#:phases
+       (modify-phases %standard-phases
+         (add-after 'unpack 'bootstrap
+           (lambda _
+             (patch-shebang "autogen.sh")
+             (zero? (system* "./autogen.sh")))))))
+    (native-inputs
+     `(("autoconf" ,autoconf)
+       ("automake" ,automake)
+       ("pkg-config" ,pkg-config)))
+    (inputs
+     `(("curl" ,curl)
+       ("openssl" ,openssl)
+       ("libxml2" ,libxml2)
+       ("libsysfs" ,sysfsutils)))
     (synopsis "Random number generator daemon")
     (description
      "Monitor a hardware random number generator, and supply entropy
-- 
2.15.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 3503 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 248 bytes --]

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

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]

Leo Famulari <leo@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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 980 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 248 bytes --]

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

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 166 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 248 bytes --]