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

[Mandy Chung]

> On Feb 16, 2016, at 5:20 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> 
> 
> On 2/16/2016 22:54, Alan Bateman wrote:
>> 
>> On 16/02/2016 14:44, Weijun Wang wrote:
>>> Please review the code change at
>>> 
>>>   http://cr.openjdk.java.net/~weijun/8130302/webrev.00/
>>> 
>>> I didn't abandon -providerClass and go all the way to -provideName
>>> because -providerClass has a sub-option -providerArg that can be used
>>> to further configure the provider. Also I think we still need to
>>> support legacy providers that are not defined in modules.
>>> 
>>> With this fix, -providerClass accepts both a provider name and a
>>> provider class name. Some doc change will be needed.
>> How is -providerName used today? I'm just trying to understand why these
>> tools have had both -providerName and -providerClass options when they
>> appear to take the same value.
> 
> Technically they are independent.
> 
> With -providerClass/-providerArg, the provider is added into system and getInstance() calls (of keyStore, KeyPairGenerator, etc) can use it.
> 
> On the other hand, -providerName can be used to specifically tell KeyPairGenerator which provider to use. For example, although both SUN and SunPKCS11 providers support RSA key pair generation, you cannot store keys generated by SunPKCS11 into a file-based keystore because the private key is kept inside the hardware token. In this case, you might want to tell keytool which provider should be used.
> 

-providerName is only used to specify the provider name for KeyStore.getInstance(storetype, providerName) call.

I think it’s best to keep this as it is.

> This bug is about loading providers not registered in java.security, which is what -providerClass/-providerArg is doing now. -providerClass and -providerName used to take different values, one class name, and one provider name. It is after modularization that -providerClass is able to take a provider name.

Can I say -providerClass <NAME> -providerArg <ARG> is equivalent to extending java.security to add “security.provider.N=NAME ARG”?

I suggest to keep -providerClass and -providerArg only for legacy security provider (i.e. not a service provider to java.security.Provider).

For security providers that are converted to service provider:

What about updating -provider <NAME>[:<ARG>] option such that (1) it accepts “provider name” only (not class name) and (2) an optional argument?  Although it’s an incompatible change, for legacy security provider, they can still use -providerClass option.

Mandy