Hi, This thread seems to have gone quite for some time. Re-Reading the thread I don't see any solutions being proposed that will truly suit everyone.
If I have correctly understood the problem we are seeing a change from a more open and trusting software environment to one with more emphasis on security that is also less trusting: * More packages are requiring the use of the kernel's high quality entropy pool (including aspects of the kernel itself) * At the same time questions are being asked over how much we can trust our entropy sources. There is no agreement of which sources we should trust; this appears to be based upon a cultural perspective rather than evidence based. * Different platforms may have different entropy sources available to them (think desktops, mobile devices, headless servers, small IoT devices & virtualised instances) What does this mean for Buster? Some services may take a long time to start. I am not talking about a few seconds here, but instead minutes or even hours. I myself see sshd timing out and being restarted by systemd several times before finally starting some 7 min after the rest of the system on my ARM64 Mustang platform. I have seen reports of taking literally several hours for all services to start on some NAS boxes. Unfortunately some services fail to start completely, others are terminated and unlimited restart attempts are made. In all cases, that I have seen, there is no mention of the reason for the failed start being that there is insufficient entropy available. This itself is a bug whatever your view on how to address lack of available entropy during start-up. We should at the very least state the reason a service has not started. I believe that systemd has the ability to only start services when a given event has happened (i.e. wait for network). Should we be asking for wait for “entropy pool > x bytes” before starting a given service? Should we add to or change the possible entropy sources? Increasing the number of different sources of entropy may well reduce the time waiting for sufficient entropy, (although this is not an excuse not to explain why a service has failed to start). There has been some discussion about adding in further possible entropy sources, and whether or not that source is enabled by default of not. In general nobody appears to be arguing against having the ability to use additional entropy sources, the only debate is over which should be enabled by default within debian. This debate appears to boil down to ‘do I trust this source’ and it is accepted that this is very much dependant upon what the installation is going to be used for AND your geo-political leanings. i.e. you may well trust a HRNG for an Intel device if you are an American, but be less inclined to trust one from China, and vice versa. I don't think that we can OR SHOULD make a sensible decision for an out of the box experience that will suitable for all users. Perhaps instead we should consider a tool (to be included in DI as well as just the archive) that can present the different options and allow the user to decide? If this is the way we as a project decide to go I would very much like to be involved in this new package. Such a tool is probably beyond my ability to write, however I would be very happy to work on the design, UI and testing. Is this the right approach to take? Best regards Andy