[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

[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

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

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

Seeding the Linux RNG at first boot

[Leo Famulari]

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

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

Exactly, this is along the lines of what I'm thinking for `guix system
vm`.

On the guest side, we would extend urandom-seed-service to also draw on
/dev/hwrng, which is where virtio-rng-pci makes the data from the host
available.

Currently there is the rngd-service-type, but that is doing something
slightly different. Using /dev/hwrng to seed urandom could be done
whenever it's enabled in the kernel.

I have an idea for another improvement: to add an argument like
"--entropy-seed=" to `guix system` that could place the value in
'/var/lib/random-seed', where it would be used on first boot.

Thoughts?

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

Re: Seeding the Linux RNG at first boot

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Dec 06, 2017 at 12:11:36AM +0100, Marius Bakke wrote:
>> 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.
>
> Exactly, this is along the lines of what I'm thinking for `guix system
> vm`.
>
> On the guest side, we would extend urandom-seed-service to also draw on
> /dev/hwrng, which is where virtio-rng-pci makes the data from the host
> available.

Maybe ‘virtualized-operating-system’ in (gnu system vm) could
automatically customize ‘rngd-service-type’ (or add it)?

> Currently there is the rngd-service-type, but that is doing something
> slightly different. Using /dev/hwrng to seed urandom could be done
> whenever it's enabled in the kernel.
>
> I have an idea for another improvement: to add an argument like
> "--entropy-seed=" to `guix system` that could place the value in
> '/var/lib/random-seed', where it would be used on first boot.

We could do that, though I very much prefer the idea of a “backdoor” à
la virtio-rng-pci, because it allows to stick to bit-reproducible images
(well, they’re not bit-reproducible yet I suppose, but let’s not add to
it.)

WDYT?

Ludo’.

Re: Seeding the Linux RNG at first boot

[Leo Famulari]

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

On Thu, Dec 07, 2017 at 10:07:38PM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > On the guest side, we would extend urandom-seed-service to also draw on
> > /dev/hwrng, which is where virtio-rng-pci makes the data from the host
> > available.
> 
> Maybe ‘virtualized-operating-system’ in (gnu system vm) could
> automatically customize ‘rngd-service-type’ (or add it)?

Yes, we could do that, although I don't think it's necessary to run a
daemon continuously. It is enough to seed the RNG once.

At the same time we handle the random seed, we could also try reading
from /dev/hwrng and, if the read is successful, copy some bytes into
/dev/urandom. We'd have to try reading and handle failure since we
always create /dev/hwrng regardless of whether the Linux kernel module
is loaded or not.

> > I have an idea for another improvement: to add an argument like
> > "--entropy-seed=" to `guix system` that could place the value in
> > '/var/lib/random-seed', where it would be used on first boot.
> 
> We could do that, though I very much prefer the idea of a “backdoor” à
> la virtio-rng-pci, because it allows to stick to bit-reproducible images
> (well, they’re not bit-reproducible yet I suppose, but let’s not add to
> it.)

I think it would be most useful for disk images, for which there is no
host.

If one always passes the same value to --entropy-seed, it will not
negatively affect the reproducibility of the image ;)

This would not be something we do for the official release image, but
merely an optional tool.

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

Re: Seeding the Linux RNG at first boot

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Thu, Dec 07, 2017 at 10:07:38PM +0100, Ludovic Courtès wrote:
>> Leo Famulari <leo@famulari.name> skribis:
>> > On the guest side, we would extend urandom-seed-service to also draw on
>> > /dev/hwrng, which is where virtio-rng-pci makes the data from the host
>> > available.
>> 
>> Maybe ‘virtualized-operating-system’ in (gnu system vm) could
>> automatically customize ‘rngd-service-type’ (or add it)?
>
> Yes, we could do that, although I don't think it's necessary to run a
> daemon continuously. It is enough to seed the RNG once.
>
> At the same time we handle the random seed, we could also try reading
> from /dev/hwrng and, if the read is successful, copy some bytes into
> /dev/urandom. We'd have to try reading and handle failure since we
> always create /dev/hwrng regardless of whether the Linux kernel module
> is loaded or not.

OK.

>> > I have an idea for another improvement: to add an argument like
>> > "--entropy-seed=" to `guix system` that could place the value in
>> > '/var/lib/random-seed', where it would be used on first boot.
>> 
>> We could do that, though I very much prefer the idea of a “backdoor” à
>> la virtio-rng-pci, because it allows to stick to bit-reproducible images
>> (well, they’re not bit-reproducible yet I suppose, but let’s not add to
>> it.)
>
> I think it would be most useful for disk images, for which there is no
> host.

OK, in that case the “backdoor” isn’t an option.

> If one always passes the same value to --entropy-seed, it will not
> negatively affect the reproducibility of the image ;)
>
> This would not be something we do for the official release image, but
> merely an optional tool.

Yeah it’d be OK to add this as an option.

When the option is present, ‘guix system’ would hook into the VM
creation code somehow, or to extend ‘activation-service-type’ with code
to create the file.

Maybe we could provide a more generic --copy-file=SOURCE[=DEST] option?
Like --copy-file=./my-seed=/var/lib/random-seed or
--copy-file=$HOME/.ssh/authorized_keys.

Thoughts?

Ludo’.

Re: Seeding the Linux RNG at first boot

[Leo Famulari]

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

On Mon, Dec 11, 2017 at 10:16:42AM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > At the same time we handle the random seed, we could also try reading
> > from /dev/hwrng and, if the read is successful, copy some bytes into
> > /dev/urandom. We'd have to try reading and handle failure since we
> > always create /dev/hwrng regardless of whether the Linux kernel module
> > is loaded or not.
> 
> OK.

Okay, I'll work on adding this to the urandom-seed-service.

> > If one always passes the same value to --entropy-seed, it will not
> > negatively affect the reproducibility of the image ;)
> >
> > This would not be something we do for the official release image, but
> > merely an optional tool.
> 
> Yeah it’d be OK to add this as an option.
> 
> When the option is present, ‘guix system’ would hook into the VM
> creation code somehow, or to extend ‘activation-service-type’ with code
> to create the file.
> 
> Maybe we could provide a more generic --copy-file=SOURCE[=DEST] option?
> Like --copy-file=./my-seed=/var/lib/random-seed or
> --copy-file=$HOME/.ssh/authorized_keys.
> 
> Thoughts?

That sounds good to me. I'll try implementing it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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 --]