I am somewhat worried about this package being added to Debian. The kernel itself is responsible for collecting randomness from interrupts when it is deemed safe enough, this is NOT a task well suited to userspace. Userspace should gather entropy from external sources (like audio noise, USB HRNGs, or an entropy data feed over the network).
Timer interrupts are the most dangerous of them all for entropy gathering: there are strong correlations between the userspace process scheduler and timer interrupts and the kernel timers/clocks, the NOHZ tickless mode interferes with it, and any hypervisor/VM environment will interfere a lot with timekeeping as well. Both light loads and heavy loads may cause timer jitter to have a lot less noise than expected. One would need to have statistically significant proof that the operations implemented by the maxwell daemon are indeed enough to provide the expected entropy on a variety of scenarios that are relevant to the timers and to the process scheduler, *using the Debian kernel targetted for release*, on every arch it is going to be available for. This does not seem feasible. Also, the BIAS on anything related to interfering with the system RNG must be on security, and not on "small fast program". I don't think we should accept this package in Debian as-is. I recommend it to be restricted to archs where it was tested, which is x86-64 right now (more can be added if either the maintainer or upstream does the required testing using diehard). I also recommend that at least the high syscall load be addressed upstream first (batch several seconds worth of entropy, and feed it in just one ioctl syscall to the kernel). It would also be advisable to ship it configured by default in Debian to credit at most 50%-70% of entropy, so as to account for unexpected behaviour on the process cheduler and system timers. I'd also recommend that it be tested first in a VM environment, using maxwell -t inside a VM to generate the required (gigabytes) of data to a file (lightly-loaded VM), and then to run diehard on the result. The test with a heavy-loaded VM can be done by just running maxwell and diehard in a pipe configuration inside the same VM. Initial entropy at very early boot, before Debian seeds the kernel, is a task that can only be done properly by the kernel itself, and is being addressed there at this time (patches have already been proposed). The proper fix for better initial entropy at boot is to backport these changes to the Debian kernel. I do not consider maxwell relevant for this scenario. For other entropy gathering needs, there are safer choices. This should be reflected on the package description. Another concern is that maxwell looks like an academic work from upstream, it would be best to talk to upstream to check their medium and long-term plans for maintaining maxwell, etc. before we commit to shipping maxwell in Debian stable. As long as it is not shipped in Wheezy, this is not an immediate or very pressing concern, as it is relatively harmless to remove packages that are present only on testing and unstable, and never made it to a stable Debian release. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
