[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-security-dev
Subject:    [8] Code Review Request for 8004044: Lazily instantiate SunJCE.RANDOM
From:       sean.mullan () oracle ! com (Sean Mullan)
Date:       2012-11-29 16:34:47
Message-ID: 50B78EA7.3000706 () oracle ! com
[Download RAW message or body]

On 11/28/2012 10:23 PM, Brad Wetmore wrote:
> Sean,
>
> Could you please provide a little more background for the motivation for
> this fix?  I'm not quite following yet how we get into this situation.
> (Bear with me, I'm not familiar with ServiceLoader yet, so this may be a
> beginner's question.)
>
> In our current implementation, there's always been the assumption that
> the order of providers is specified by the java.security file, and
> possibly tweaked by Security.*provider() code, thus ensuring that
> requested algs will come from the highest ordered provider at the time
> of initialization.  Is this going away?

TBD. As part of project jigsaw, I prototyped loading JCE providers using 
ServiceLoader. There are a few issues that need to be resolved in the 
JDK 9 timeframe, including:

1. There is no preference order for services loaded by ServiceLoader

I addressed this by aggressively loading all providers, and then 
reordering them based on the ordering in the java.security file. This is 
not ideal, but it works.

2. There is no mechanism to specify an additional configuration file

This is used by our PKCS11 provider, for example. I hacked around this 
by passing it the config file after it had been instantiated, but again 
this is not ideal.

More information on each of these issues and a few others is here:

http://bugs.sun.com/view_bug.do?bug_id=7191104

> FYI, the current behavior when no providers have been registered as
> Security Providers is to directly create a SHA1PRNG.
>
> The code itself is ok, even without the upcoming change to ServiceLoader.

Ok, thanks.

--Sean

>
> Brad
>
>
> On 11/28/2012 8:53 AM, Sean Mullan wrote:
>> Please review the following webrev which lazily initializes the
>> SecureRandom object used by the SunJCE provider.
>>
>> In JDK 9, we want to load JCE providers with java.util.ServiceLoader as
>> part of the transition to modules. This can cause potential recursive
>> loading issues if the Sun provider for SecureRandom has not been loaded
>> yet (since providers are loaded in no specific order using
>> ServiceLoader). The fix is to lazily instantiate SunJCE.RANDOM. This is
>> a proactive fix that will smooth the transition to modules.
>>
>> There is no regression test as this is a small refactoring that is
>> covered by existing tests. The bug has been tagged with the
>> noreg-cleanup label.
>>
>> The bug is not up on bugs.sun.com yet.
>> bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004044
>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8004044/webrev.00
>>
>> Thanks,
>> Sean



[prev in list] [next in list] [prev in thread] [next in thread]