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

[Mandy Chung]

> On Feb 21, 2016, at 1:45 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
> 
>> On Feb 20, 2016, at 4:01 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> 
>> 
>>> 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).
> 
> Dup or not dup?

Not to dup.  But you have the point better to duplicate the code.

> 
>> 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. 
> 
> I still like to write some new lines. ProviderConfig is not public and I don't intend to make it so. Since keytool/jarsigner does not need to care about security manager, there is no need for those doPrivileged calls. Also, I still want the compatibility lines below.
> 
>> 
>> 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.
> 
> We discourage it, but there are quite some examples like this on the net. It is the only way to load a SunPKCS11 provider with a user-specified config file.


Is there any particular providers you mostly concern about (SUN, PKCS11?)?  I prefer to keep -providerClass for legacy non-service providers to avoid inconsistency with java.security config.  Perhaps you can add aliases for few specific provider ie. -providerClass sun.security.provider.Sun is alias to -provider SUN and document them in the man page to help migration.

Mandy

> 
>> 
>> 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”.
> 
> -providerName is not needed because KeyPairGenerator will pick it anyway. I still need "-providerClass sun.security.provider.Sun" so it runs on jdk9/dev. The jake change can use "-provider 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.
> 
> I see them. Performance enhancement? Probably not crucial here since a normal user should never use -providerClass to load these providers. -providerClass should only be used when 1) a config argument is needed 2) the provider is not registered in java.security.
> 
> Thanks
> Max
> 
>> 
>> Mandy
>> 
>