Bug#923675: debian-installer: delays when using an https mirror due to rng

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#923675: debian-installer: delays when using an https mirror due to rng

Cyril Brulebois-4
Package: debian-installer
Severity: important

Spotted with the netboot-gtk-french-with-https playbook of the tiny d-i
test suite, that sets a few command line parameters:

    mirror/protocol=https
    mirror/https/hostname=deb.debian.org
    mirror/https/directory=/debian

the initial choose-mirror scanning of the repository takes ages (up to
several minutes, if one doesn't interact with the VM):

    Mar  3 17:09:12 syslogd started: BusyBox v1.27.2
    […]
    Mar  3 17:09:31 choose-mirror[1710]: DEBUG: command: wget --no-verbose https://deb.debian.org/debian/dists/oldstable/Release -O - | grep -E '^(Suite|Codename|Architectures):'
    Mar  3 17:11:51 kernel: [  161.130075] random: crng init done
    Mar  3 17:11:51 kernel: [  161.130086] random: 7 urandom warning(s) missed due to ratelimiting
    Mar  3 17:11:52 choose-mirror[1710]: DEBUG: command: wget --no-verbose https://deb.debian.org/debian/dists/jessie/Release -O - | grep -E '^(Suite|Codename|Architectures):'
    Mar  3 17:11:53 choose-mirror[1710]: DEBUG: command: wget --no-verbose https://deb.debian.org/debian/dists/stable/Release -O - | grep -E '^(Suite|Codename|Architectures):'
    Mar  3 17:11:53 choose-mirror[1710]: DEBUG: command: wget --no-verbose https://deb.debian.org/debian/dists/stretch/Release -O - | grep -E '^(Suite|Codename|Architectures):'
    Mar  3 17:11:54 choose-mirror[1710]: DEBUG: command: wget --no-verbose https://deb.debian.org/debian/dists/testing/Release -O - | grep -E '^(Suite|Codename|Architectures):'
    Mar  3 17:11:54 choose-mirror[1710]: DEBUG: command: wget --no-verbose https://deb.debian.org/debian/dists/buster/Release -O - | grep -E '^(Suite|Codename|Architectures):'
    Mar  3 17:11:55 choose-mirror[1710]: DEBUG: command: wget --no-verbose https://deb.debian.org/debian/dists/unstable/Release -O - | grep -E '^(Suite|Codename|Architectures):'
    Mar  3 17:11:56 choose-mirror[1710]: DEBUG: command: wget --no-verbose https://deb.debian.org/debian/dists/sid/Release -O - | grep -E '^(Suite|Codename|Architectures):'
    Mar  3 17:11:56 choose-mirror[1710]: INFO: suite/codename set to: testing/buster

Any advice on how to fix/mitigate this appreciated.


Cheers,
--
Cyril Brulebois ([hidden email])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Reply | Threaded
Open this post in threaded view
|

Bug#923675: debian-installer: delays when using an https mirror due to rng

Colin Watson
I don't have much advice on fixing it, but I expect that network-console
has a similar problem since it also needs randomness in order to deal
with SSH.

--
Colin Watson                                       [[hidden email]]

Reply | Threaded
Open this post in threaded view
|

Bug#923675: Add related bug #916690 info

Daniel Lange-2
In reply to this post by Cyril Brulebois-4
This is related to #916690.

getrandom() essentially blocks during many use cases where the system
does not have enough entropy. This is somewhat mitigated by the Debian
kernel now trusting the RDRAND (CONFIG_RANDOM_TRUST_CPU) for AMD64
(https://lists.debian.org/debian-devel/2019/02/msg00170.html) which has
this CPU instruction on somewhat recent hardware. Other architectures
and a number of virtualization setups on AMD64 are still running into
this issue.

The Debian Installer variant of this issue is the hardest* to solve.
So I fear we're in "add it to the release notes"-land again.

For Bullseye (or a point release) we should solve the problem more
comprehensively.

* The Debian Installer media cannot have a (carried over consecutive
boots) seed file embedded. This makes it the hardest case to solve as
one needs to "reach out" for entropy sources.
Downloading some random bytes from {random.org | random.debian.org} and
feeding to the entropy pool proper (ioctl RNDADDENTROPY) would solve
this for networked hosts, able to reach such an external entropy source.
Of course there is an attack vector added by reaching out to the net. So
this would need proper configurability to make it safe to use. Note: we
cannot use cryptography to protect this ... the PRNG is the very thing
in need of proper initialization here.
And for non-network hosts or ones shielded from the Internet and not run
in a proper data center environment (that would probably supply a
random.the-hoster.tld service) this will not improve the situation.

Thorsten Glaser (CC) has produced a prototype early-rng-init-tools (cf.
https://lists.debian.org/debian-devel/2019/02/msg00327.html) which could
be extended to try reading entropy off the network when it doesn't have
a carried-over seed (as in the Debian Installer case).

Reply | Threaded
Open this post in threaded view
|

Bug#923675: Add related bug #916690 info

Petter Reinholdtsen
Debian Edu ran into this problem when installing Kerberos as a server from d-i,
and solved it by running a process in the background to monitor the entropy level,
and when it was running low, it would flush the file buffers and run 'find
/target' to force some IO operations that would add entropy to the kernel.

The code can be found in
<URL: https://salsa.debian.org/debian-edu/debian-edu-config/blob/master/share/debian-edu-config/d-i/finish-install >
and look like this:


# Try to add entropy when running low
(
   cd /
   while true ; do
       entropy="$(cat /proc/sys/kernel/random/entropy_avail)"
       if [ 130 -gt "$entropy" ] ; then
           log "low on entropy, pool is $entropy. trying to add more"
           # Disk IO add entropy to the kernel.  Flush cache to ensure find and
           # touch/rm causes disk IO.
           sync
           echo 3 > /proc/sys/vm/drop_caches
           find /target > /dev/null || true
           touch /target/var/tmp/foo
           sync
           rm /target/var/tmp/foo
           sync
           entropy="$(cat /proc/sys/kernel/random/entropy_avail)"
           log "entropy pool is $entropy after trying to add"
       fi
       sleep 20
   done ) < /dev/null 2>&1 3>/dev/null 4>&3 5>&3 6>&3 | logger -t edu-entropy-add
& epid=$!

... install stuff ...

# Ignore errors in case the entropy gathering is no longer running
if kill $epid ; then
    :
else
    log "error: killing the entropy gathering job failed - exited?"
fi

Perhaps a similar approach could be inserted into the default Debian Installer?

--
Happy hacking
Petter Reinholdtsen

Reply | Threaded
Open this post in threaded view
|

Bug#923675: Add related bug #916690 info

Ben Hutchings-3
On Tue, 2019-04-16 at 12:19 +0200, Petter Reinholdtsen wrote:
> Debian Edu ran into this problem when installing Kerberos as a server from d-i,
> and solved it by running a process in the background to monitor the entropy level,
> and when it was running low, it would flush the file buffers and run 'find
> /target' to force some IO operations that would add entropy to the kernel.
[...]

This is a pretty terrible approach.  Especially as the world has moved
on to SSDs and they provide very little entropy from interrupts.

Ben.

--
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#923675: Add related bug #916690 info

Petter Reinholdtsen
[Ben Hutchings]
> This is a pretty terrible approach.  Especially as the world has moved
> on to SSDs and they provide very little entropy from interrupts.

Absolutely.  But it has solved the  problem with too little entropy since 2011.
Do you have any better ways to force the kernel to add some entropy when running
low?

--
Happy hacking
Petter Reinholdtsen

Reply | Threaded
Open this post in threaded view
|

Bug#923675: Add related bug #916690 info

Thorsten Glaser
In reply to this post by Daniel Lange-2
Daniel Lange dixit:

> Thorsten Glaser (CC) has produced a prototype early-rng-init-tools (cf.
> https://lists.debian.org/debian-devel/2019/02/msg00327.html) which could be
> extended to try reading entropy off the network when it doesn't have a
> carried-over seed (as in the Debian Installer case).

Sorry, this is deliberately out of scope.

My early-rng-init-tools is exactly for the use case of carrying a random
seed between boots and making it available to the system earlier (as a
stopgap until all bootloaders support passing it to the kernel before
the latter is even run) and *deliberately* does not touch the part where
entropy is collected.

FWIW, downloading entropy can be done (we have this in the MirBSD
installer) but has privacy concerns, so it should perhaps be optional.
This is easily done in d-i components, except for the little fact that
busybox wget in d-i lacks https support.

I’ve built myself a locally patched 'monolith' installer with extra
entropy over the network, but that’s site-dependent.

Also, please don’t assume everyone has amd64. The m68k people will,
among others, thank you ;-)

bye,
//mirabilos
--  
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Reply | Threaded
Open this post in threaded view
|

Bug#923675: Add related bug #916690 info

Ben Hutchings-3
In reply to this post by Petter Reinholdtsen
On Tue, 2019-04-16 at 13:57 +0200, Petter Reinholdtsen wrote:
> [Ben Hutchings]
> > This is a pretty terrible approach.  Especially as the world has moved
> > on to SSDs and they provide very little entropy from interrupts.
>
> Absolutely.  But it has solved the  problem with too little entropy since 2011.
> Do you have any better ways to force the kernel to add some entropy when running
> low?

haveged or jitterentropy-rngd are likely to be better.

Ben.

--
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#923675: Add related bug #916690 info

Cyril Brulebois-4
Ben Hutchings <[hidden email]> (2019-04-16):

> On Tue, 2019-04-16 at 13:57 +0200, Petter Reinholdtsen wrote:
> > [Ben Hutchings]
> > > This is a pretty terrible approach.  Especially as the world has moved
> > > on to SSDs and they provide very little entropy from interrupts.
> >
> > Absolutely.  But it has solved the  problem with too little entropy since 2011.
> > Do you have any better ways to force the kernel to add some entropy when running
> > low?
>
> haveged or jitterentropy-rngd are likely to be better.
The former was on my list of things to try; thanks for mentioning the latter.


Cheers,
--
Cyril Brulebois ([hidden email])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#923675: Add related bug #916690 info

Petter Reinholdtsen
In reply to this post by Ben Hutchings-3
[Ben Hutchings]
> haveged or jitterentropy-rngd are likely to be better.

Is there any hope to run them within d-i in Buster before /target/ is
set up?

--
Happy hacking
Petter Reinholdtsen

Reply | Threaded
Open this post in threaded view
|

Bug#923675: debian-installer: consider using haveged to gather entropy

Cyril Brulebois-4
In reply to this post by Cyril Brulebois-4
Control: retitle -1 debian-installer: consider using haveged to gather entropy

Cyril Brulebois <[hidden email]> (2019-04-16):
> The former was on my list of things to try; thanks for mentioning the
> latter.

I'm no cryptographer so I cannot judge haveged from that angle.

But from a /proc/sys/kernel/random/entropy_avail standpoint, starting
the haveged daemon inside d-i, a couple of screens after the graphical
installer start-up, I'm getting a bump from ~150 to ~2500.

This needs to be polished before submitting the addition of haveged-udeb
and of course proper integration needs to happen, with real tests… For
wget, we're hitting #926315, but it was luckily closed a couple hours
ago; arm devices that need so much time to generate a keypair should get
a nice improvement…


My initial thought would be to launch it on demand when one is about to
get to wget calls that needs HTTPS; but we could probably benefit from
it in case HTTP is requested but redirections to HTTPS happens… There
are also the obvious keypair generations mentioned above. But then over
time maybe some other operations could be needing entropy (the
cryptsetup case is discussed in a separate thread[1]).

 1. https://lists.debian.org/debian-boot/2019/04/msg00153.html

So it might be best to start it unconditionally at start-up?


Cheers,
--
Cyril Brulebois ([hidden email])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#923675: debian-installer: consider using haveged to gather entropy

Steve McIntyre
On Tue, Apr 16, 2019 at 11:45:08PM +0200, Cyril Brulebois wrote:
>Cyril Brulebois <[hidden email]> (2019-04-16):
>> The former was on my list of things to try; thanks for mentioning the
>> latter.

...

>My initial thought would be to launch it on demand when one is about to
>get to wget calls that needs HTTPS; but we could probably benefit from
>it in case HTTP is requested but redirections to HTTPS happens… There
>are also the obvious keypair generations mentioned above. But then over
>time maybe some other operations could be needing entropy (the
>cryptsetup case is discussed in a separate thread[1]).
>
> 1. https://lists.debian.org/debian-boot/2019/04/msg00153.html
>
>So it might be best to start it unconditionally at start-up?

I'd go with that, yes. What's the down-side?

I'm also pondering doing something similar with "udevadm monitor" -
start it unconditionally, logging to the installer syslog. It'd be a
good extra bit of debug to have.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
Google-bait:       http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Reply | Threaded
Open this post in threaded view
|

Bug#923675: debian-installer: consider using haveged to gather entropy

Jonathan Carter-6
In reply to this post by Cyril Brulebois-4
On 2019/04/16 23:45, Cyril Brulebois wrote:
> I'm no cryptographer so I cannot judge haveged from that angle.

Ditto here, but...

> But from a /proc/sys/kernel/random/entropy_avail standpoint, starting
> the haveged daemon inside d-i, a couple of screens after the graphical
> installer start-up, I'm getting a bump from ~150 to ~2500.
>
> This needs to be polished before submitting the addition of haveged-udeb
> and of course proper integration needs to happen, with real tests… For
> wget, we're hitting #926315, but it was luckily closed a couple hours
> ago; arm devices that need so much time to generate a keypair should get
> a nice improvement…

Yeah debian-live was unusable without haveged (as in, some sessions
wouldn't start up for hours unless users pounded on the keyboard for a
while). Some people quickly get hand-wavy about haveged, but it seems
like the theory of how it works is reasonably solid and I really tried
to find evidence of it being harmful or not generating enough randomness
in typical use cases, but couldn't find anything, so we went ahead and
included it in the live media and it seems to work for us there.

Debian's official documentation probably just needs a section explaining
what haveged is and that if someone needs to create a mass amount of
keys for commercial applications or such then it's really recommended
that they get a decent hardware RNG or use an external service to seed that.

-Jonathan

Reply | Threaded
Open this post in threaded view
|

Bug#923675: debian-installer: consider using haveged to gather entropy

Ben Hutchings-3
In reply to this post by Cyril Brulebois-4
On Tue, 2019-04-16 at 23:45 +0200, Cyril Brulebois wrote:
[...]

> My initial thought would be to launch it on demand when one is about to
> get to wget calls that needs HTTPS; but we could probably benefit from
> it in case HTTP is requested but redirections to HTTPS happens… There
> are also the obvious keypair generations mentioned above. But then over
> time maybe some other operations could be needing entropy (the
> cryptsetup case is discussed in a separate thread[1]).
>
>  1. https://lists.debian.org/debian-boot/2019/04/msg00153.html
>
> So it might be best to start it unconditionally at start-up?
Ideally it would only be used if there isn't a hardware RNG available.
Currently we don't include any hardware RNG modules in udebs, but that
can be changed.  So please first check that:

* /sys/devices/virtual/misc/hw_random/rng_current is absent or
  contains "none"
* (x86 only) /proc/cpuinfo does not mention rdrand (I can't find an
  arch-independent way to check for this, and Linux doesn't yet
  support an equivalent feature on any other architecture)

Something like this should work:

if [ "$(cat /sys/devices/virtual/misc/hw_random/rng_current 2>/dev/null || echo none)" = none ] \
   && ! grep -q '^flags\b.*\brdrand\b' /proc/cpuinfo; then
    # use software entropy daemon
fi

Ben.

--
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#923675: Bug#927111: unblock: wpa/2:2.7+git20190128+0c1e29f-4

Cyril Brulebois-4
In reply to this post by Cyril Brulebois-4
Niels Thykier <[hidden email]> (2019-04-18):
> Cyril Brulebois:
> > I think it'd be nice to have some tests on a real wireless adapter,
> > which I'll try to get to in the next days, because of the amount of
> > patching involved. That shouldn't stop you from letting the package
> > reach testing first though.

As noted on #debian-devel when discussing this a bit with Andrej: I've
had issues passing an USB adapter through kvm but tests on bare metal
look good with this new wpa package. I didn't perform a full install
though as I wanted to retain my main system. ;)

Getting slightly off-topic but still relevant to other areas that want
to see work done before the buster release: Both tests in VM and on bare
metal made me confirm what I thought could be possible → we're also
affected by entropy starvation (#923675) in the wireless stack.


Cheers,
--
Cyril Brulebois ([hidden email])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#923675: debian-installer: consider using haveged to gather entropy

Cyril Brulebois-4
In reply to this post by Ben Hutchings-3
Control: tag -1 patch pending

Hi,

Ben Hutchings <[hidden email]> (2019-04-17):

> Ideally it would only be used if there isn't a hardware RNG available.
> Currently we don't include any hardware RNG modules in udebs, but that
> can be changed.  So please first check that:
>
> * /sys/devices/virtual/misc/hw_random/rng_current is absent or
>   contains "none"
> * (x86 only) /proc/cpuinfo does not mention rdrand (I can't find an
>   arch-independent way to check for this, and Linux doesn't yet
>   support an equivalent feature on any other architecture)
>
> Something like this should work:
>
> if [ "$(cat /sys/devices/virtual/misc/hw_random/rng_current 2>/dev/null || echo none)" = none ] \
>    && ! grep -q '^flags\b.*\brdrand\b' /proc/cpuinfo; then
>     # use software entropy daemon
> fi
Many thanks for your input and for the suggested implementation.

I've tweaked it a little so that we log whether haveged is available,
and whether it should be started, in case we need to investigate:
  https://salsa.debian.org/installer-team/rootskel/blob/master/src/lib/debian-installer-startup.d/S50entropy-source


I think I've tested all cases:
 - when haveged-udeb hasn't been added to src:debian-installer's
   pkg-lists yet
 - with the default Skylake-Client in libvirt, which leads to an rdrand
   CPU flag;
 - with a core2duo CPU instead, which has no such flag;
 - with the same CPU, but with a VirtIO RNG enabled, and those extra
   kernel modules in my netboot-gtk image:
     lib/modules/4.19.0-4-amd64/kernel/drivers/char/hw_random/rng-core.ko
     lib/modules/4.19.0-4-amd64/kernel/drivers/char/hw_random/virtio-rng.ko
     lib/modules/4.19.0-4-amd64/kernel/drivers/virtio/virtio.ko
     lib/modules/4.19.0-4-amd64/kernel/drivers/virtio/virtio_ring.ko
   which leads to a virtio_rng.0 in …/hw_random/rng_current.


So I've just uploaded a new version of rootskel (1.129), and pushed a
new commit to debian-installer:
  https://salsa.debian.org/installer-team/debian-installer/commit/c470001925d067b42cdf613339634f4d54ed01b6

The haveged-udeb addition was already uploaded and also ACCEPTED from
NEW. I'll keep an eye on the daily builds.


Cheers,
--
Cyril Brulebois ([hidden email])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#923675: debian-installer: consider using haveged to gather entropy

Holger Levsen-2
On Sat, Apr 20, 2019 at 02:39:49AM +0200, Cyril Brulebois wrote:
> I've tweaked it a little so that we log whether haveged is available,
> and whether it should be started, in case we need to investigate:
>   https://salsa.debian.org/installer-team/rootskel/blob/master/src/lib/debian-installer-startup.d/S50entropy-source

nice work!

does that also mean that haveged get's installed on the final system if
it's deemed to be useful in d-i or is that still missing?


--
tschau,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#923675: debian-installer: consider using haveged to gather entropy

Cyril Brulebois-4
Hi Holger,

Holger Levsen <[hidden email]> (2019-04-20):
> On Sat, Apr 20, 2019 at 02:39:49AM +0200, Cyril Brulebois wrote:
> > I've tweaked it a little so that we log whether haveged is available,
> > and whether it should be started, in case we need to investigate:
> >   https://salsa.debian.org/installer-team/rootskel/blob/master/src/lib/debian-installer-startup.d/S50entropy-source
>
> nice work!
>
> does that also mean that haveged get's installed on the final system if
> it's deemed to be useful in d-i or is that still missing?

There's nothing in what I have written (on this bug report or in the
code I've quoted or pointed to) that references /target, no.


TBF I have no idea whether we should do that; the situation is slightly
different as a non-installer/non-live system can carry over entropy from
one boot to the next one, which d-i can't do.

I've focussed on getting entropy issues within d-i fixed, which seemed
urgently needed. I'm fine with people seeking a consensus through
debian-boot@ (and maybe debian-devel@) regarding what should happen in
the installed system.

(I almost mentioned the fix would be trivial as it's about pulling an
extra package, but since we have no rng support in udebs at the moment,
we would have no rng support in d-i thus haveged running, while the
installed system could have rng support… Anyway: deciding what to do is
the important part; implementation should be much more straightforward
than the haveged udeb addition dance I've just orchestrated.)


Cheers,
--
Cyril Brulebois ([hidden email])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#923675: debian-installer: consider using haveged to gather entropy

Holger Levsen-2
Hi Cyril,

On Sat, Apr 20, 2019 at 11:28:23PM +0200, Cyril Brulebois wrote:
> > does that also mean that haveged get's installed on the final system if
> > it's deemed to be useful in d-i or is that still missing?
> There's nothing in what I have written (on this bug report or in the
> code I've quoted or pointed to) that references /target, no.

this was my understanding as well, though I wasn't sure (havent reviewed
the code), thats why I asked, so thanks for pointing this out! (and for
the other feedback as well!)

> TBF I have no idea whether we should do that; the situation is slightly
> different as a non-installer/non-live system can carry over entropy from
> one boot to the next one, which d-i can't do.

right.

> I've focussed on getting entropy issues within d-i fixed, which seemed
> urgently needed. I'm fine with people seeking a consensus through
> debian-boot@ (and maybe debian-devel@) regarding what should happen in
> the installed system.

ok, cool.

though I don't think I have time/energy to drive this discussion right
now :/

> (I almost mentioned the fix would be trivial as it's about pulling an
> extra package, but since we have no rng support in udebs at the moment,
> we would have no rng support in d-i thus haveged running, while the
> installed system could have rng support… Anyway: deciding what to do is
> the important part; implementation should be much more straightforward
> than the haveged udeb addition dance I've just orchestrated.)

heh. what was the reason haveged was choosen and not jitterentropy-rngd
which was also suggested here?


--
tschau,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#923675: debian-installer: consider using haveged to gather entropy

Cyril Brulebois-4
Holger Levsen <[hidden email]> (2019-04-22):
> heh. what was the reason haveged was choosen and not
> jitterentropy-rngd which was also suggested here?

I have enough things to keep me busy; if the first one I look at can be
turned into something useful in d-i, seems to have reasonable integration
and maintenance costs, and has a maintainer who is happy to let me modify
the packaging accordingly, then it's unlikely I'll spend more time looking
at an alternative.

Not that I wouldn't appreciate such a comparison in theory; in practice,
time is limited. If others want to compare both, feel free to.


Cheers,
--
Cyril Brulebois ([hidden email])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

signature.asc (849 bytes) Download Attachment