2010/1/16 Drew Farris <drew.far...@gmail.com>:
> On Sat, Jan 16, 2010 at 4:42 PM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>> . Running through strace showed
>>> that something was attempting to reading from /dev/random. Sometimes
>>> it ran fine, but at least 25-30% it ended up blocking until the
>>> entropy pool is refilled. To test I moved /dev/random, and created a
>>> link from /dev/urandom to /dev/random (the former doesn't block, but
>>> isn't cryptographically secure). It looks as if this could be related
>>> to the loading of the SecureRandomSeedGenerator class.
>>
>> Why not use a fixed random seed for unit tests? That would make them
>> more repeatable and avoid this problem, no?
>>
>
> It appears we are. in RandomUtils:
>
> public static Random getRandom() {
> return testSeed ? new MersenneTwisterRNG(STANDARD_SEED) : new
> MersenneTwisterRNG();
> }
>
> But something somewhere is forcing SecureRandomSeedGenerator to get
> loaded by the classloader which in turn does a 'new SecureRandom()' in
> a private static final field assignment. Trying to track down what is
> causing the generator to get loaded in the first place.
>
> But something is forcing the SecureRandomSeedGenerator class to get
> loaded, which I suspect
>
MersenneTwisterRNG constructor calls:
this(DefaultSeedGenerator.getInstance().generateSeed(SEED_SIZE_BYTES));
Which in turn calls:
private static final SeedGenerator[] GENERATORS = new SeedGenerator[]
{
new DevRandomSeedGenerator(),
new RandomDotOrgSeedGenerator(),
new SecureRandomSeedGenerator()
};
In the definition of the class: DefaultSeedGenerator
Unless the forking tests are disabled I don't see how to prevent the
MersenneTwisterRNG to inderctly fetch entropy from /dev/random /
SecureRandom.
--
Olivier
http://twitter.com/ogrisel - http://code.oliviergrisel.name
