Remove haveged as extra/unnecessary package.
Also useless for new kernels as per this post.
mixed responses from distro engineers, also dunno about kernel 6.x if this is even more not relevant, since it doesnt make issues, ok lets keep and see.
haveged has been removed from qubes.
Which distro engineers?
Without a rationale, discussion, that would not be an argument for removal from Whonix either. This commit was done in context of (Re)move Debian packages in `packages.list` and `packages_minimal.list` Ā· Issue #6566 Ā· QubesOS/qubes-issues Ā· GitHub, which is a source code cleanup / refactoring task. Not an argument against haveged
/ for haveged
removal.
Also, no. haveged
was not removed from Qubes.
haveged
was removed from packages_minimal.list
file, yes. But it is still part of the ānormalā, ānon-minimalā packages.list
file.
Even if removed from packages.list
it could still be part of qubes-meta-packages
. (It currently does not seem to be. I am just explanation that looking at a single file, single commit is insufficinet to predict what packages will be installed by default in Qubes.)
I havenāt found a ticket for haveged
removal from Qubes and I am not creating one either because I am not convinced of it.
Every major distro you can think of doesnt include it by default (debian, redhat, fedoraā¦etc) and even warn against installing it.
Removed from Manjaro, rantional can be found here.
Debian packaging issue: latest version packaged in debian was 1.9.14 released in 2021, however upstream version is 1.9.18 released in 2022 which has not included for over 2 years into debian (or possibly ever).
The maintainer himself called it obsoleteā¦
So not sure about the idea of having it for the future kernel versions, because its unknown how will that mess things up.
haveged has a test suite. Itās tested. (haveged) Itās passing. Itās maintained.
Bad wording from 2021. This was revised in 2022 and readme also updated in 2022.
Based on bad wording from 2021.
These arenāt security-focused Linux distributions. Especially Debian unfortunately isnāt on the forefront of entropy improvements.
Debian:
What another distribution does or not does is by itself not an argument. Elaborated here, written just now: Why donāt you do what does?
They acknowledge:
This article or section is out of date.
Anyhow. Letās see the warning.
Warning: The quality of the generated entropy is not guaranteed and sometimes contested (see LCE: Do not play dice with random numbers and Is it appropriate to use haveged as a source of entropy on virtual machines?). Use it at your own risk or use it with a hardware based random number generator with the rng-tools (see #Alternative section)
So lets see who is ācontestingā (just another poor word choice) what.
I am following it to the sources.
Quote LCE: Do not play dice with random numbers
āāSo, while I canāt really recommend it, I canāt not recommend it either.āā
So no contesting there.
contesting ā researching
If you are going to run HAVEGE, Peter strongly recommended running it together with rngd, rather than as a replacement for it.
Great. Thatās what we are doing. Kinda. We donāt use rngd because that requires an additional hardware device. We donāt rely only on haveged. Multiple sources of entropy are being used. This is documented here: Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND
I am not aware of any other Linux distribution documenting the topic of entropy in this detail.
āAt its heart, [HAVEGE] uses timing information based on the processorās high resolution timer (the RDTSC instruction). This instruction can be virtualized, and some virtual machine hosts have chosen to disable this instruction, returning 0s or predictable results.ā
(Source: PolarSSL Security Advisory 2011-02 on polarssl.org).
polarssl issue. They should use the proper kernel APIs and not any entropy daemon directly. The bug report can be translated to āpolarssl should not use a single entropy source (haveged) by default but instead use kernel APIā. Right. Not a haveged issue.
The kernel is careful about changing the randomness interface, isnāt in the business of breaking APIs (kernel development policy is: ādonāt break userspaceā), let alone breaking the APIs in a way leading to existing applications worsening entropy.
The good thing is that jirka is still active, lets hope hes following latest kernel changes to avoid any issues (although the current functionality of haveged with recent kernel versions not sure if anywhere mentioned how its improving things except with what jirka has mentioned).
Good to read as well āMyths about /dev/urandomā.
related:
Did a few tests. All my systems run fine without haveged (and have been so for a few years, actually ā silly me)
Adding it does not increase available entropy or its quality at all.
Useful ticket.
Operating on outdated information.
Not about information, its practical test.
Just the developer of the tool saying its doing anything more useful.
lets see if debian is going to be interested to include it for the next releases.
Not about information, its practical test.
The only thing which was states was tested was cat /proc/sys/kernel/random/entropy_avail
which is a very superficial test, that doesnāt say much.
Just the developer of the tool saying its doing anything more useful.
Quote from the ticket:
Did a few tests. All my systems run fine without haveged (and have been so for a few years, actually ā silly me)
Adding it does not increase available entropy or its quality at all.
There is not much that shows much substance.
Did a few tests.
What tests?
All my systems run fine without haveged
āRuns fineā isnāt an entropy quality test. The system would run fine even if the entropy was completely predictable.
(and have been so for a few years, actually ā silly me)
Indicates, that the author isnāt much focused on the topic of entropy. Otherwise, having haveged installed versus not makes quite a difference.
Adding it does not increase available entropy
Not important. Full pool is full pool.
or its quality at all.
Author didnāt say how quality was tested.
Iāll ask in the ticket.
There is no such issue. If that ever was an issue, it seems to have been fixed nowadays.
Thanks for testing this! @arraybolt3
1.9.19
has been uploaded to Debian as per above link.