all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [bug#29542] rng-tools: New upstream location, new releases
@ 2017-12-03  0:31 Leo Famulari
  2017-12-03 19:49 ` Tobias Geerinckx-Rice
  0 siblings, 1 reply; 13+ messages in thread
From: Leo Famulari @ 2017-12-03  0:31 UTC (permalink / raw)
  To: 29542


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

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [bug#29542] rng-tools: New upstream location, new releases
  2017-12-03  0:31 [bug#29542] rng-tools: New upstream location, new releases Leo Famulari
@ 2017-12-03 19:49 ` Tobias Geerinckx-Rice
  2017-12-04 18:45   ` Leo Famulari
  2017-12-06  2:38   ` Tobias Geerinckx-Rice
  0 siblings, 2 replies; 13+ messages in thread
From: Tobias Geerinckx-Rice @ 2017-12-03 19:49 UTC (permalink / raw)
  To: leo, 29542


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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [bug#29542] rng-tools: New upstream location, new releases
  2017-12-03 19:49 ` Tobias Geerinckx-Rice
@ 2017-12-04 18:45   ` Leo Famulari
  2017-12-05 23:11     ` Marius Bakke
                       ` (2 more replies)
  2017-12-06  2:38   ` Tobias Geerinckx-Rice
  1 sibling, 3 replies; 13+ messages in thread
From: Leo Famulari @ 2017-12-04 18:45 UTC (permalink / raw)
  To: Tobias Geerinckx-Rice; +Cc: 29542

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [bug#29542] rng-tools: New upstream location, new releases
  2017-12-04 18:45   ` Leo Famulari
@ 2017-12-05 23:11     ` Marius Bakke
  2017-12-06 18:27       ` Seeding the Linux RNG at first boot Leo Famulari
  2017-12-20  8:55       ` bug#29542: rng-tools: New upstream location, new releases Leo Famulari
  2017-12-06  2:33     ` [bug#29542] " Tobias Geerinckx-Rice
  2017-12-06 18:07     ` Leo Famulari
  2 siblings, 2 replies; 13+ messages in thread
From: Marius Bakke @ 2017-12-05 23:11 UTC (permalink / raw)
  To: Leo Famulari, Tobias Geerinckx-Rice; +Cc: 29542

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [bug#29542] rng-tools: New upstream location, new releases
  2017-12-04 18:45   ` Leo Famulari
  2017-12-05 23:11     ` Marius Bakke
@ 2017-12-06  2:33     ` Tobias Geerinckx-Rice
  2017-12-06 18:07     ` Leo Famulari
  2 siblings, 0 replies; 13+ messages in thread
From: Tobias Geerinckx-Rice @ 2017-12-06  2:33 UTC (permalink / raw)
  To: leo; +Cc: 29542


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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [bug#29542] rng-tools: New upstream location, new releases
  2017-12-03 19:49 ` Tobias Geerinckx-Rice
  2017-12-04 18:45   ` Leo Famulari
@ 2017-12-06  2:38   ` Tobias Geerinckx-Rice
  1 sibling, 0 replies; 13+ messages in thread
From: Tobias Geerinckx-Rice @ 2017-12-06  2:38 UTC (permalink / raw)
  To: leo, 29542


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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [bug#29542] rng-tools: New upstream location, new releases
  2017-12-04 18:45   ` Leo Famulari
  2017-12-05 23:11     ` Marius Bakke
  2017-12-06  2:33     ` [bug#29542] " Tobias Geerinckx-Rice
@ 2017-12-06 18:07     ` Leo Famulari
  2 siblings, 0 replies; 13+ messages in thread
From: Leo Famulari @ 2017-12-06 18:07 UTC (permalink / raw)
  To: Tobias Geerinckx-Rice; +Cc: 29542

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Seeding the Linux RNG at first boot
  2017-12-05 23:11     ` Marius Bakke
@ 2017-12-06 18:27       ` Leo Famulari
  2017-12-07 21:07         ` Ludovic Courtès
  2017-12-20  8:55       ` bug#29542: rng-tools: New upstream location, new releases Leo Famulari
  1 sibling, 1 reply; 13+ messages in thread
From: Leo Famulari @ 2017-12-06 18:27 UTC (permalink / raw)
  To: guix-devel

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Seeding the Linux RNG at first boot
  2017-12-06 18:27       ` Seeding the Linux RNG at first boot Leo Famulari
@ 2017-12-07 21:07         ` Ludovic Courtès
  2017-12-07 23:47           ` Leo Famulari
  0 siblings, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2017-12-07 21:07 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Seeding the Linux RNG at first boot
  2017-12-07 21:07         ` Ludovic Courtès
@ 2017-12-07 23:47           ` Leo Famulari
  2017-12-11  9:16             ` Ludovic Courtès
  0 siblings, 1 reply; 13+ messages in thread
From: Leo Famulari @ 2017-12-07 23:47 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Seeding the Linux RNG at first boot
  2017-12-07 23:47           ` Leo Famulari
@ 2017-12-11  9:16             ` Ludovic Courtès
  2017-12-11 16:08               ` Leo Famulari
  0 siblings, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2017-12-11  9:16 UTC (permalink / raw)
  To: Leo Famulari; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Seeding the Linux RNG at first boot
  2017-12-11  9:16             ` Ludovic Courtès
@ 2017-12-11 16:08               ` Leo Famulari
  0 siblings, 0 replies; 13+ messages in thread
From: Leo Famulari @ 2017-12-11 16:08 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#29542: rng-tools: New upstream location, new releases
  2017-12-05 23:11     ` Marius Bakke
  2017-12-06 18:27       ` Seeding the Linux RNG at first boot Leo Famulari
@ 2017-12-20  8:55       ` Leo Famulari
  1 sibling, 0 replies; 13+ messages in thread
From: Leo Famulari @ 2017-12-20  8:55 UTC (permalink / raw)
  To: 29542-done

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2017-12-20  8:56 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-12-03  0:31 [bug#29542] rng-tools: New upstream location, new releases Leo Famulari
2017-12-03 19:49 ` Tobias Geerinckx-Rice
2017-12-04 18:45   ` Leo Famulari
2017-12-05 23:11     ` Marius Bakke
2017-12-06 18:27       ` Seeding the Linux RNG at first boot Leo Famulari
2017-12-07 21:07         ` Ludovic Courtès
2017-12-07 23:47           ` Leo Famulari
2017-12-11  9:16             ` Ludovic Courtès
2017-12-11 16:08               ` Leo Famulari
2017-12-20  8:55       ` bug#29542: rng-tools: New upstream location, new releases Leo Famulari
2017-12-06  2:33     ` [bug#29542] " Tobias Geerinckx-Rice
2017-12-06 18:07     ` Leo Famulari
2017-12-06  2:38   ` Tobias Geerinckx-Rice

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.