> On Feb 21, 2016, at 1:45 AM, Wang Weijun <weijun.w...@oracle.com> wrote:
>
>
>> 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?
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
>>
>
