RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules
Weijun Wang
weijun.wang at oracle.com
Thu Feb 18 08:10:12 UTC 2016
>> In keytool help, we will write
>>
>> -provider <providername> Add a security provider with its name
>
> “Add a security provider by the provider’s name”
>
>> -providerArg <arg> Optional argument for -provider above
>> -providerClass <providerclass> Add a security provider with its class name
>
> “Add a security provider by a fully-qualified classname”
>
>> -providerArg <arg> Optional argument for -providerClass above
>>
>> This is also what you are thinking about, right?
>>
>
> Yes this matches what I suggest.
>
>> You think the implementation should strictly match the help above, and I think we can treat -provider and -providerClass the same and perform a try-name-first-try-class-second trick just like what sun.security.jca.ProviderConfig.ProviderLoader::load is doing.
>
> You may consider adding a method in sun.security.jca.ProviderConfig for keytool to call rather than duplicating the logic.
>
>>
>> The -providerClass was introduced in https://bugs.openjdk.java.net/browse/JDK-4938224:
>>
>> To avoid confusion, the -provider option should
>> be renamed to -providerClass. The -provider should still
>> be supported (although not documented) for compatibility.
>>
>> I still see 3 regression tests using -provider this way and I don't want to break them.
>>
>
> The option is not documented and repurpose -provider option may not be commonly used. These regression tests should be re-examined whether they can be updated to use -providerClass.
Yes, they can be updated, but I can imagine there are external customer
doing the same.
There is another compatibility issue which is more important:
Today, we tell users to load their own PKCS11 provider with
-providerClass sun.security.pkcs11.SunPKCS11 -providerArg some.cfg
and seems the new options should be
-provider SunPKCS11 -providerArg some.cfg
Why not just support all these formats? It's not really difficult and I
don't think it's harmful, no ambiguity, simple code...
--Max
More information about the security-dev
mailing list