This is a meta/reminder/discussion ticket for the removal of rng-tools and surrounding components, which, due to the kernel entropy change discussed in #12893, may or may not be no longer needed.
There is a button at the bottom right of the page to clone tickets. That's useful because it pre-fills some fields.
(In reply to Michael Tremer from comment #1) > There is a button at the bottom right of the page to clone tickets. That's > useful because it pre-fills some fields. Oh, I missed this. Thanks - will keep it in mind for the next time.
Created attachment 1067 [details] Content of /etc/init.d/rngd
Created attachment 1068 [details] Content of /etc/udev/rules.d/99-TrueRNGpro.rules
I have attached the contents of my current configuration files for rngd.
Is there no proper kernel driver available for this device at all?
@Michael: No, it's designed to be accessed as a TTY device with >3.2 Mbps output.
An alternative is to change rng-tools from a core program to an addon. That way it is still available for those who have a hardware generator and require it but is not installed in the IPFire machines that don't need it.
"An alternative is to change rng-tools from a core program to an addon." May I ask that this be added to TTD? Doing so would allow closure of #11546. Also, there is a bug fix release available: https://github.com/nhorman/rng-tools/releases/tag/v6.15 Thank you!
I am very pleased that the rng-tools discussion made it to the Monthly Teleconference. There is yet another bug fix / feature release available (6.16). The aforementioned (related) bug, #11546, has an attachment, text for a two line change to services.cgi, that may prove helpful, even if rng-tools is moved to addon status and the changes no longer apply. Thank you!
Searching on rng-tools after the changes to the entropy pool in kernel 5.6 onwards I have found that the kernel will still take information from rng-tools but only after the kernel has completed gatheri9ng the required entropy itself. It will then combine the HWRNG data in an XOR with the entropy that the kernel has already gathered to the required level. Therefore using an HWRNG does not give you the required entropoy quicker or to a higher level than the kernel does itself. It will in fact be to the same level and later than the entropy obtained by the kernel itself. It seems to me that the only reason to use a HWRNG now is if you don't trust the entropy gathered by the kernel and want to combine entropy from an HWRNG with the entropy from the kernel to dilute the entropoy from the kernel with that of the HWRNG. So rng-tools could be kept as an addon but the benefit of using that for combining the HWRNG entropy with that of the kernel seems to be a bit unclear.
"rng-tools could be kept as an addon" Please, make it so.
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=f4b849cb3fb839d8eec6fb8a682f85cabd2f7d71
https://blog.ipfire.org/post/ipfire-2-27-core-update-174-is-available-for-testing
Tested this out on my vm testbed with CU 174 Testing and can confirm that rng-tools is now an addon and that after installing it, it also shows up in the addon s service table. This confirms that this bug has been fixed.
Thank you, all! I eagerly await the release of CU 174 (I have no spare hdwe to use for testing).
Good work, Team! Thanks to all!
https://blog.ipfire.org/post/ipfire-2-27-core-update-174-released