On 27 July 2011 10:57, Bruno Friedmann <bruno@ioda-net.ch> wrote:
One of the other reason to have it enabled early in the installation process or just before you start configuring things is : ssl key generation think about vpn server, dns, ldap, CA, ssh keys, ssl/tls vhosts, databases tls connexion and will become more and more used : dns signing zone DNSSEC
Yeap typically not a workstation usage, but pretty much all server pattern should have it.
No ?
Including something in default install does not really HELP anyone, but imposes taxes (adds a small cost on) very many installations that don't need it. So I think that is logically the WORST option of all. After all it's easy with zypper to install packages eg) "zypper in haveged; chkconfig haveged on" as Olipro said, the problem is knowing you need it. It is better to do nothing and not install haveged at all, at least the objectors are then happy.. Patterns sound better to me than the "if install to runlevel 3" idea. Because it's quite legitimate to install to graphical or text, and then change default run level later, or have graphical display idle without UI. But including via recommends or server pattern something that operates "on demand" when entropy consumers are installed actually does target real useage. I think avoiding slowing boot up is the basis for Coolo's objection. And according to http://www.issihosts.com/haveged/ 1) "Ultimately, I decided that urandom was a bad idea. To see why, look at figure 2.1 in Gutterman, Pinkas, and Reinman (page 5). You will see that pulling from an empty urandom pool, triggers a fill from the primary entropy pool - the thing you are trying to fill! I don't know of anyone who has really tested what the result of this is, but the output of any pseudo random number generator has to have a hardware seed somewhere and this arrangement looks prone to generating artifacts. And since there is no check on data sanity in this arrangement so who knows what is really in the random pools?" Which is one answer to Jeff's question "why not pull from /dev/urandom to fill random". 2) "The daemon suspends itself on the random device waiting for a write_low_watemark event." Suggests something may be doable with systemd, to trigger entropy suplementation on demand, which is "interesting". Especially if Cristian Rodríguez as haveged maintainer isn't set on a hardware or in kernel solution, meaning he'd reject on principal contributions which explore this possibility. in /proc/sys/kernel/random we have : entropy_avail poolsize write_wakeup_threshold read_wakeup_threshold So would a solution that reacts to low entropy, that remains consistently low for 5 or 10 seconds, be in principal acceptable, even if it only reported via log likely entropy starvation? Regards Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org