Red Hat Bugzilla – Bug 200653
rebuild-security-providers should set securerandom.source
Last modified: 2007-11-30 17:11:39 EST
Description of problem:
When I run azureus on rawhide, VMSecureRandom::Spinner::run() consumes about 70%
of my CPU (as reported by oprofile), making the system as whole quite unusable.
I don't know what's up with that method, but we can avoid the whole mess by
adding the following line to /usr/lib/security/classpath.security:
This is what Casey recommends anyways here:
My system was practically unusable when I was running azureus before I made this
change, but now it seems fine.
It looks like this would have to happen in rebuild-security-providers.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Generate secure random numbers with gcj
The pegged-CPU issue was caused by GCJ not supporting `volatile' properly; this
should be fixed on trunk. If not, you might want to reopen GCC bug 27908. Note,
it's pretty simple to work around, too (see comment 8 in that bug).
But also, setting `securerandom.source' to `/dev/urandom' is a perfectly fine
solution on GNU/Linux (using `/dev/random' may cause your program to hang), and
is preferable, because we don't really know how good the random bytes we create
using thread-spinners are.
I can confirm this is fixed on trunk, not on 4.1 branch.
This would be fixed by the GNU Classpath 0.92 backport.
(In reply to comment #3)
> This would be fixed by the GNU Classpath 0.92 backport.
How is this fixed? Is /dev/urandom the default random number source in 0.92?
(In reply to comment #4)
> (In reply to comment #3)
> > This would be fixed by the GNU Classpath 0.92 backport.
> How is this fixed? Is /dev/urandom the default random number source in 0.92?
Yes, see mjw's note on fedora-devel-java-list.
Fixed in Rawhide by the latest libgcj backport. classpath.security now has this