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

Wang Weijun weijun.wang at oracle.com
Fri Feb 19 08:22:09 UTC 2016


A new webrev at

   http://cr.openjdk.java.net/~weijun/8130302/webrev.01/

The options for keytool have

 -provider <name> [-providerArg <arg>]        add a provider by name
 -providerclass <class> [-providerArg <arg>]  add a provider by classname

(omit some words because line is too long)

for jarsigner

  [-provider <name>           add a security provider by a provider name
    [-providerArg <arg>]] ... configure argument for -provider

  [-providerClass <class>     add a security provider by a fully-qualified classname
    [-providerArg <arg>]] ... configure argument for -providerClass

In the test AltProvider.java, I compiled 2 classes (DummyProvider and module-info) for a new module and they manually create the modulepath directory. Is there a more formal way to do that?

Thanks
Max

> On Feb 18, 2016, at 10:55 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> On Feb 18, 2016, at 1:52 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> 
>> On 18/02/2016 09:08, Weijun Wang wrote:
>>> OK, but with -providerClass I'd like to support a class name even if it is already defined in a module as a service and has its own name. This makes sure old commands still work.
>> I think it should work fine but I assume we would want to discourage this. That is, these security providers are service provider and there should be no need for anyone to know the name of the implementation class.
>> 
> 
> Exactly.
> 
> Note that the current ProviderConfig implementation doesn’t support security.provider.N=<classname> if this is loaded from the another named module.  It should throw IAE.
> 
> Mandy




More information about the security-dev mailing list