RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

Mandy Chung mandy.chung at oracle.com
Fri Feb 19 20:01:54 UTC 2016


> On Feb 19, 2016, at 2:47 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
> Updated at the same URL
> 
>  http://cr.openjdk.java.net/~weijun/8130302/webrev.01
> 
> The help looks like this now:
> 
> -provider <name>          add security provider by name (e.g. SunPKCS11)
>   [-providerArg <arg>]      configure argument for -provider
> -providerclass <class>    add security provider by fully-qualified classname
>   [-providerArg <arg>]      configure argument for -providerclass
> 

The help message looks good.  

On the change, I suggest not to duplicate the code from ProviderConfig (I mentioned in my previous reply).  One way to do is to add sun.security.jca.Providers.addProvider(String name, String argument) that will do the same as loading a provider listed in java.security config file (ProviderConfig::getProvider I believe).  I think this change can go into jdk9/dev as ProviderConfig has the right changes there. 

 303             // A provider in module can also be use class name
 304             if (p.getClass().getName().equals(provClass)) {

ProviderConfig::getProvider doesn’t compare the classname. I thought we agree to discourage the use of -providerClass to load a provider and also will be consistent with java.security.

1719         testOK("", "-list -storepass password" +
1720                 " -providerClass sun.security.provider.Sun" +
1721                 " -keystore x.jks -storetype JKS”);

This should use -providerName.  You may want to test both “sun.security.provider.Sun” and “SUN”.

ProviderConfig::getProvider has some fast path to support both classname and provider name for our built-in security providers for compatibility because these names are used in java.security.

Mandy



More information about the jigsaw-dev mailing list