Bug 200653 - rebuild-security-providers should set securerandom.source
rebuild-security-providers should set securerandom.source
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: jpackage-utils (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-29 20:44 EDT by Anthony Green
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-30 13:55:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anthony Green 2006-07-29 20:44:24 EDT
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:

securerandom.source=file:/dev/random

This is what Casey recommends anyways here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

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):


How reproducible:
Always

Steps to Reproduce:
1.Generate secure random numbers with gcj 
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Casey Marshall 2006-07-30 16:36:50 EDT
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.
Comment 2 Andrew Haley 2006-07-31 05:57:40 EDT
I can confirm this is fixed on trunk, not on 4.1 branch.
Comment 3 Thomas Fitzsimmons 2006-07-31 10:39:24 EDT
This would be fixed by the GNU Classpath 0.92 backport.
Comment 4 Anthony Green 2006-07-31 10:44:49 EDT
(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?
Comment 5 Thomas Fitzsimmons 2006-07-31 10:46:56 EDT
(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.
Comment 6 Thomas Fitzsimmons 2006-08-30 13:55:02 EDT
Fixed in Rawhide by the latest libgcj backport.  classpath.security now has this
line:

securerandom.source=file:/dev/random

Note You need to log in before you can comment on or make changes to this bug.