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
