Haveged has actually become higher priority with 12.1. I was advocating enabling it by default so I'm surprised to see that development has gone the opposite way. In releases prior to 12.1, drivers for popular network devices contributed to the entropy pool. Those patches weren't getting much traction upstream so we dropped them in the 12.1 kernel. The entropy pool will not be replenished as quickly on 12.1 naturally so haveged being enabled by default would be a good idea. -Jeff -- Jeff Mahoney (apologies for the top post -- from my mobile) On Jul 24, 2011, at 11:02 AM, Lars Müller wrote:

On Sun, Jul 24, 2011 at 03:19:47PM +0100, Olipro wrote:

...

I see someone else made a post back in May about this and I was wondering if anything came of it since; This daemon is sadly disabled by default in 11.4 which results in /dev/random having very little available entropy at all and thus anything that uses /dev/random for key generation will tend to stall for inordinate amounts of time, especially on systems that are only running from the commandline, for example, I have occasionally seen DNSSEC tutorials for openSUSE which use /dev/urandom - something that I think is just insane, but most likely a result of nothing being available to fill the entropy pool.

See https://bugzilla.novell.com/show_bug.cgi?id=675841 which was refereced by the haveged package change log.

- avoid unnecessary services. bnc#675841 also the start should be mediated by YaST or kiwi depending on presence of a virtualization environment, not by the package itself.

Would it enhance the result if the installer suggest to enable haveged if we decide to operate in runlevel 3?

The amount of black magic in changing defaults in the background without notifying the user must kept as minimal as possible.

Please drive this via bugzilla to make references in the package change log to the bug IDs possible. In bugzilla you're able to place a pointer to the archive of this mailing list thread http://lists.opensuse.org/opensuse-factory/2011-07/msg00378.html

Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 07/26/2011 02:34 PM, Marcus Meissner wrote:

Hi,

The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time.

We reviewed haveged for SLE 11, from a integrity security side it is ok.

We reviewed the randomness it generates briefly (!) and found no issues.

However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me.

It insanity rating is similar to using /dev/urandom, refering to a previous comment.

That said, we are fine with enabling it if people consider it necessary.

Ciao, Marcus

On Sun, Jul 24, 2011 at 03:34:23PM -0400, Jeff Mahoney wrote:

...

Haveged has actually become higher priority with 12.1. I was advocating enabling it by default so I'm surprised to see that development has gone the opposite way.

In releases prior to 12.1, drivers for popular network devices contributed to the entropy pool. Those patches weren't getting much traction upstream so we dropped them in the 12.1 kernel. The entropy pool will not be replenished as quickly on 12.1 naturally so haveged being enabled by default would be a good idea.

-Jeff

-- Jeff Mahoney (apologies for the top post -- from my mobile)

On Jul 24, 2011, at 11:02 AM, Lars Müller wrote:

...

On Sun, Jul 24, 2011 at 03:19:47PM +0100, Olipro wrote:

...

I see someone else made a post back in May about this and I was wondering if anything came of it since; This daemon is sadly disabled by default in 11.4 which results in /dev/random having very little available entropy at all and thus anything that uses /dev/random for key generation will tend to stall for inordinate amounts of time, especially on systems that are only running from the commandline, for example, I have occasionally seen DNSSEC tutorials for openSUSE which use /dev/urandom - something that I think is just insane, but most likely a result of nothing being available to fill the entropy pool.

See https://bugzilla.novell.com/show_bug.cgi?id=675841 which was refereced by the haveged package change log.

- avoid unnecessary services. bnc#675841 also the start should be mediated by YaST or kiwi depending on presence of a virtualization environment, not by the package itself.

Would it enhance the result if the installer suggest to enable haveged if we decide to operate in runlevel 3?

The amount of black magic in changing defaults in the background without notifying the user must kept as minimal as possible.

Please drive this via bugzilla to make references in the package change log to the bug IDs possible. In bugzilla you're able to place a pointer to the archive of this mailing list thread http://lists.opensuse.org/opensuse-factory/2011-07/msg00378.html

Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Marcus, I'm using haveged, for example on a multi-purpose webserver dns, hosting etc. here the munin report about the entropy with haveged on (until May it was a 11.2 openSUSE) Last month http://dl.dropbox.com/u/13333867/openSUSE/haveged-entropy-month.png Last year http://dl.dropbox.com/u/13333867/openSUSE/havged-entropy-year.png I can push several other hosts, with same kind of data. Just ask. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 26 July 2011 14:07, Marcus Meissner wrote:

On Tue, Jul 26, 2011 at 02:43:05PM +0200, Bruno Friedmann wrote: ... The bad thing is that a cryptographic encrypted stream of pseudo randomness is not really distinguishable from real randomness.

You would need to evaluate the underlying technology.

How is that a bad thing? If you can't distinguish, then how could an attacker exploit it? I understand that some deployments will want to have carefully "unquestionable" entropy sources, but that appears to me to be an argument to enable haveged in general. May be I'm missing something, but for general installation with practical relaxed requirements this sounds like a "feature", a remote attacker would have problems to "evaluate the underlying technology" to select target. Regards Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, Jul 26, 2011 at 09:35:33AM -0400, Jeff Mahoney wrote:

On 07/26/2011 08:34 AM, Marcus Meissner wrote:

...

Hi,

The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time.

We reviewed haveged for SLE 11, from a integrity security side it is ok.

We reviewed the randomness it generates briefly (!) and found no issues.

However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me.

It insanity rating is similar to using /dev/urandom, refering to a previous comment.

That said, we are fine with enabling it if people consider it necessary.

Hrm, if the quality is indistinguishable from /dev/urandom, why wouldn't we just pump from /dev/urandom when /dev/random runs out?

I just wanted to point out that it is hard to differ real entropy and pseudo randomness. haveged claims to derive randomness from timer fluctuations in calculations and cache timings and cache flushings, and we used timer based randomness when feeding from network cards and human input devices. As long as the CPUs don't have predictable timings in the used calculations currently haveged can be used for "real" entropy. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tuesday 26 Jul 2011 15:01:33 Marcus Meissner wrote:

On Tue, Jul 26, 2011 at 09:35:33AM -0400, Jeff Mahoney wrote:

...

On 07/26/2011 08:34 AM, Marcus Meissner wrote:

...

Hi,

The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time.

We reviewed haveged for SLE 11, from a integrity security side it is ok.

We reviewed the randomness it generates briefly (!) and found no issues.

However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me.

It insanity rating is similar to using /dev/urandom, refering to a previous comment.

That said, we are fine with enabling it if people consider it necessary.

Hrm, if the quality is indistinguishable from /dev/urandom, why wouldn't we just pump from /dev/urandom when /dev/random runs out?

I just wanted to point out that it is hard to differ real entropy and pseudo randomness.

haveged claims to derive randomness from timer fluctuations in calculations and cache timings and cache flushings, and we used timer based randomness when feeding from network cards and human input devices.

As long as the CPUs don't have predictable timings in the used calculations currently haveged can be used for "real" entropy.

Ciao, Marcus

If you find it "too good to be true" then here's a very simple experiment you can do to demonstrate exactly how big of a difference there is between pseudo- random and actually (or indeterminable from random) data there is. 1) remove/disable all sources of entropy as best as you possibly can 2) dd if=/dev/random of=/dev/null obs=16 3) watch /proc/sys/kernel/random/entropy_avail until available entropy drops to around the 100 mark. 4) dd if=/dev/urandom of=/dev/random - we are now dumping pseudo-random data directly into the kernel's RNG entropy pool. 5) observe how it fails to make absolutely any difference to entropy_avail You can thus rest assured that the microtime a CPU takes to perform x number of loops will never be the same ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rob Davies wrote:

On 27 July 2011 08:23, Olipro wrote:

...

I believe it's also worth pointing out that haveged only feeds the data into the kernel, it does not manipulate the entropy estimate - therefore, even if someone were to hack or replace haveged with something that feeds the kernel non-random data, the kernel will simply not increase its entropy estimate.

It's quite a while since I looked at the Fate entry on entropy sources being required, and the experimental code I wrote which played with timers is deleted long ago, but IIRC you needed to increase the kernel's estimate of entropy, to stop the blocking, not just do the data writing. The kernel estimating the randomness of data written to /dev/random sounds expensive.

Did anyone look at "audio entropy daemon" http://www.vanheusden.com/aed/ which aims to use static noise from unused sound card? Presumably such would be widely available thanks to integrated audio, even on diskless installs.

Perhaps except on servers - none of mine have on-board sound. /Per -- Per Jessen, Zürich (23.7°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rob Davies wrote:

On 27 July 2011 14:02, Per Jessen wrote:

...

Rob Davies wrote:

...

Presumably such would be widely available thanks to integrated audio, even on diskless installs.

Perhaps except on servers - none of mine have on-board sound.

Ok, so are your servers entropy starved or are there sufficient interrupts in practice?

Probably no and very probably yes. I wasn't trying to argue either way, just thought I'd mention it.

Would USB key type hardware be practical? Presumably your server boards are not budget models and operate in a controlled secure environment.

Yup.

Do you have (assuming you see entropy starvation and hardware solution impractical) objections to running haveged, making it poor choice?

To me (albeit with very limited understanding of the issues involved here), running haveged by default sounds like a perfectly good idea. If I needed a higher quality random source, hardware would likely be my choice.

The Fate entry I was thinking of mentioned networked diskless installations, which might need fair amount of entropy but receive less as network card contributed entropy has issues and they may have unused audio input. The timing unpredictability approach, appeared simpler to deploy, because it did not require hardware, yet seems less trusted as "real" hardware interrupts. I wondered if the audio based daemon might have a niche.

It sounds like an idea worth exploring. One thing I've been wondering about (whilst reading this thread) - in which kind of environment does the problem occur? (assuming problem = low entropy, high demand) -- Per Jessen, Zürich (20.4°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rob Davies wrote:

On 27 July 2011 18:28, Per Jessen wrote:

...

It sounds like an idea worth exploring.  One thing I've been wondering about (whilst reading this thread) - in which kind of environment does the problem occur?  (assuming problem = low entropy, high demand)

https://features.opensuse.org/306591

"Headless and diskless servers with limited input have relied on entropy added by interrupts flagged with IRQF_SAMPLE_RANDOM. However, this feature will be disappearing from the Kernel soon."

Thanks. I guess that is primarily virtual and/or blade systems with iscsi or network file systems? -- Per Jessen, Zürich (18.7°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 27 July 2011 20:45, Stefan Seyfried wrote:

Am Wed, 27 Jul 2011 18:47:15 +0100 schrieb Rob Davies :

...

The basic problem is caused by profligate consumption of entropy from /dev/random

echo "ln -sf urandom /dev/random" >> /etc/init.d/boot.local

:) But probably not what you really want to do if you distributing softate that wants to generate long lived keys. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wednesday 27 Jul 2011 08:28:44 Stephan Kulow wrote:

Am Dienstag, 26. Juli 2011 schrieb Marcus Meissner:

...

Hi,

The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time.

We reviewed haveged for SLE 11, from a integrity security side it is ok.

We reviewed the randomness it generates briefly (!) and found no issues.

However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me.

It insanity rating is similar to using /dev/urandom, refering to a previous comment.

That said, we are fine with enabling it if people consider it necessary.

I think we can easily install it by default and if someone writes a yast agent to enable it for runlevel 3 installations, I'm fine with that too. But I don't want an extra daemon running on default installs that usually don't need it - and those that do need it, can easily enable it.

Greetings, Stephan

The problem is largely that those that *do* need it probably don't actually know they need it. So if you don't want it running on default installs, rather than just blanket turning it off, do something intelligent to determine whether it should be enabled or not. How many people do you think are aware of things like the kernel's entropy pool etcetera? my bet is that the correct answer is "very few" given so many people are swapping random with urandom. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 27 July 2011 10:57, Bruno Friedmann 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

On Sunday 24 Jul 2011 17:41:25 Cristian Rodríguez wrote:

El 24/07/11 10:19, Olipro escribió:

...

something that I think is just insane,

Yes, it is insane, point your guns to kernel developers ;)

This haveged daemon is an userspace workaround, that provides strong, high quality entropy (passes all FIPS tests) but it is not a long term solution.

If you want a permanent solution, get one of this http://www.entropykey.co.uk/

Cheers.

Is this the mailing list for SuSE or random advertisements of RNG hardware? (pun intended) The issue wasn't really about grandstanding over what sort of entropy gathering should or should not be in the kernel but rather the fact that as it stands, openSUSE has a significant issue with the /dev/random device which could be alleviated by enabling haveged by default at (preferably) runlevels 3 and 5. I think what needs to be done is to make an objective evaluation of what sort of footprint haveged has on a system when left enabled by default, and weigh that cost up against the benefit of ensuring that programs using /dev/random are not impacted - personally, I would say that classifying it as "unnecessary" is disingenous and that having it enabled by default has benefits far greater than the few Kb of memory it will consume. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sunday 24 Jul 2011 19:37:25 you wrote:

On 24 July 2011 18:34, Olipro wrote:

...

On Sunday 24 Jul 2011 17:41:25 Cristian Rodríguez wrote:

...

El 24/07/11 10:19, Olipro escribió:

...

something that I think is just insane,

Yes, it is insane, point your guns to kernel developers ;)

This haveged daemon is an userspace workaround, that provides strong, high quality entropy (passes all FIPS tests) but it is not a long term solution.

If you want a permanent solution, get one of this http://www.entropykey.co.uk/

Is this the mailing list for SuSE or random advertisements of RNG hardware? (pun intended)

It brings a smile seeing a USB key described as a "permanent solution" though!

The complaint in Bug#675841, was about the Release Notes, with changes undocumented due to the low level of detail provided, https://bugzilla.novell.com/show_bug.cgi?id=675841. The Changelog for haveged item "- avoid unnecessary services. bnc#675841" appears misleading.

However http://www.issihosts.com/haveged/ suggests "haveged" isn't just a few kb, it talks about a "collects entropy harvests in a 8MB buffer which is read byte by byte", though I guess that can be paged out if you don't really need the daemon.

Another option might be to enable the daemon, on machines where entropy available becomes low and only slowly replaced. Run it on a machine, that can become entropy starved, say overnight without active UI. The daemon suspends itself on the random device waiting for a write_low_watemark event. So perhaps a stub, could do the same and intelligently enable the daemon if it appears necessary?

Rob

I believe the daemon only consumes memory when entropy gets low... it then proceeds to replenish the kernel and goes back to sleep... At least that's why a cursory google search has led me to believe; if this isn't so then surely this could be easily achieved with a small modification. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 24 July 2011 20:18, Cristian Rodríguez wrote:

El 24/07/11 14:37, Rob Davies escribió:

...

It brings a smile seeing a USB key described as a "permanent solution" though!

Well, permanent as long the USB key doesn't break or the noise generator inside is considered broken..or the the hash algorithm used (skein 256) becomes "weak"...

Or Hot unplug... Magic or an algorithmn? All kinds of things are likely to be going on in a modern OS, without your say so. cron.daily scripts, GC's, new features coming like auto-defrag on BTRFS. Having such packages uninstalled defends those who care a lot about the entropy pool, who bother with hardware solutions. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 24 July 2011 20:45, Cristian Rodríguez wrote:

...

On 24 July 2011 20:18, Cristian Rodríguez wrote:

...

El 24/07/11 14:37, Rob Davies escribió:

To do what you suggest you need exactly what the daemon itself already does, monitor the entropy amount of the system, if it goes lower than a

El 24/07/11 15:31, Rob Davies escribió: limit it starts working.

Saying "it should" be done by kernel doesn't help, when Linux 3.0 doesn't and that's what we've got. Can you really see many installs having those USB keys? (I can't, I just think, you'll get some users saying openSUSE's slow.). On demand daemon starting is an issue for 12.1, if you do it for CUPS why not something that provides entropy if it's generally not useful to most installs? It's just events, print job submitted, low water mark hit. I have not seen what the objections were to having the daemon started by default, and I pointed out that the changelog misrepresented the discussion in the bug, which was about lack of information in the release notes. Very likely that's the simplest practical solution. Far from "telling that we add another level of complexity", I just pointed out a possible alternative, rather than just blocking ignoring or reporting a problem, the system activates something to ameliorate it when it seems useful. I DO NOT care that would be ineffiecient, it is far more efficient than a call to a sysadmin. I don't understand why you think reacting to such an issue is too complicated, because good sysadmins end up writing scripts to do that kind of maintenance rather often, and there were objections to the non-obvious inclusion in Installer. Overloading the choice of run level 3 rather than 5, seems rather indirect and fragile to me; install time can be very different from real usage so dislike of that alternative is understandable. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sunday 24 Jul 2011 22:56:06 Rob Davies wrote:

On 24 July 2011 20:45, Cristian Rodríguez wrote:

...

...

On 24 July 2011 20:18, Cristian Rodríguez wrote:

...

El 24/07/11 14:37, Rob Davies escribió: To do what you suggest you need exactly what the daemon itself already does, monitor the entropy amount of the system, if it goes lower than a

El 24/07/11 15:31, Rob Davies escribió: limit it starts working.

Saying "it should" be done by kernel doesn't help, when Linux 3.0 doesn't and that's what we've got. Can you really see many installs having those USB keys? (I can't, I just think, you'll get some users saying openSUSE's slow.).

On demand daemon starting is an issue for 12.1, if you do it for CUPS why not something that provides entropy if it's generally not useful to most installs? It's just events, print job submitted, low water mark hit.

I have not seen what the objections were to having the daemon started by default, and I pointed out that the changelog misrepresented the discussion in the bug, which was about lack of information in the release notes. Very likely that's the simplest practical solution.

Far from "telling that we add another level of complexity", I just pointed out a possible alternative, rather than just blocking ignoring or reporting a problem, the system activates something to ameliorate it when it seems useful. I DO NOT care that would be ineffiecient, it is far more efficient than a call to a sysadmin. I don't understand why you think reacting to such an issue is too complicated, because good sysadmins end up writing scripts to do that kind of maintenance rather often, and there were objections to the non-obvious inclusion in Installer. Overloading the choice of run level 3 rather than 5, seems rather indirect and fragile to me; install time can be very different from real usage so dislike of that alternative is understandable.

Rob

Agreed. In any case, from having haveged running on my 11.4 box, its footprint seems to be very small, around 6Kb and it simply sits there idling; if I dd /dev/random into /dev/null then it starts consuming CPU cycles but does not increase memory consumption. I could completely understand disabling this if you were running SUSE on some embedded system where memory was incredibly tight to the point that you were compiling your own stripped-down kernel to accommodate for the fact - in all other instances, haveged is just going to sit there and do nothing if the system always has sufficient entropy. So the cost-benefit analysis is that either you cost everyone who doesn't know that they don't need haveged a few Kb of memory to have it running at all times to ensure people on entropy starved machines don't ever run into issues with applications that rely on /dev/random or you decide to save a few Kb at the cost of causing hassle for people with insufficient system entropy. the only other possibility I can think of is to have the installation environment (or some post-install runonce) attempt to empty out /dev/random and see how quickly it replenishes and use that to make a decision as to whether or not to enable haveged for that particular system, given that haveged will give you roughly 1.7MB/s of entropy. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org