> On Feb 20, 2016, at 4:01 AM, Mandy Chung <mandy.ch...@oracle.com> wrote:
>
>
>> On Feb 19, 2016, at 2:47 AM, Wang Weijun <weijun.w...@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?
> 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.
>
> 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
>
