RFR 8056174: New APIs for jar signing

[Sean Mullan]

On 09/01/2015 02:50 AM, Weijun Wang wrote:
> Updated a little: rewrite of jarsigner tool itself using the JarSigner
> API included. Still at the same URL below.

I notice that you don't use the new JarSigner API at all in the 
jarsigner tool and go straight to the BuilderX/JarSignerX classes. This 
worries me as it means the API is not sufficient for our own uses and 
therefore may not be sufficient for anyone else either.

I think the flaw is that we have not made it extensible. JarSigner is a 
final class, so it can't be subclassed with new functionality. Removing 
the final keyword would be easy, but that doesn't really solve the problem.

It looks like we are not the first ones to tackle this problem. Here is 
one link:

https://weblogs.java.net/blog/emcmanus/archive/2010/10/25/using-builder-pattern-subclasses

Can you think about this some more and see if the design can be adapted 
to allow JarSigner to be extended?

Thanks,
Sean

>
> --Max
>
> On 08/24/2015 09:56 PM, Weijun Wang wrote:
>> Hi All
>>
>> Please review the code change at
>>
>>    http://cr.openjdk.java.net/~weijun/8056174/webrev.02/
>>
>> A new JarSigner public API is introduced to OpenJDK. The code change
>> chooses a two-layer implementation style, with public JarSigner/Builder
>> in jdk.security and private JarSignerX/BuilderX in sun.security. The
>> private side contains some unpopular options which I hope can be used to
>> implement the jarsigner tool itself in another changeset.
>>
>> Some spec clarification is made since my last mail [1], including
>> Builder#sign, JarSigner#getDigestAlg, and JarSigner#getSigAlg. In
>> Builder, I am still using short method names (sigAlg, digestAlg, and
>> tsa) since I think the jarsigner option names are already widely
>> accepted. Otherwise, a name like setDigestAlgorithm seems a little
>> unfamiliar.
>>
>> Thanks
>> Max
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/security-dev/2015-August/012636.html
>>