RFR 8242260: Remove customizable ContentSigner from jarsigner

[Sean Mullan]

Fair point, these two features are tightly coupled together so it 
probably doesn't make sense to remove (or keep) one w/o the other.

So, I recommend marking the ContentSigner APIs deprecated for removal in 
15, and delaying the removal of the APIs *and* the jarsigner -altsigner 
and -altsignerpath options until 16.

Whether we remove these in 15 or 16 is not going to make much of a 
difference in the long run.

--Sean

On 4/10/20 5:07 AM, Peter Levart wrote:
> What's the use of allowing compiling some classes if those classes can't 
> be used anywhere? They would be unusable in the new release of 
> jarsigner. Ok, they could be used in some older jarsigner if the classes 
> were compiled with appropriate -release option. So the usecase for not 
> removing the classes would be in a project that builds an implementation 
> of ContentSigner and then publishes it to be used in a project that 
> still uses an old jarsigner. Such ContentSigner project could then be 
> upgraded to use the new JDK/javac with appropriate -release option for 
> compiling ContentSigner implementation classes.
> 
> Peter
> 
> On 4/10/20 3:58 AM, Wang Weijun wrote:
>> So the classes will be useless but at least old program still 
>> compiles. I'll modify the CSR and see how Joe thinks of this.
>>
>> Thanks,
>> Max
>>
>>> 在 2020年4月9日，22:58，Sean Mullan <sean.mullan at oracle.com> 写道：
>>>
>>> On 4/9/20 10:52 AM, Weijun Wang wrote:
>>>> All info for signing are passed into a ContentSigner through a 
>>>> ContentSignerParameters object. In order to pass more info, I’ll 
>>>> need to create new interface methods for it.
>>> But you can just use your solution in JarSigner in the webrev below 
>>> where you are calling PKCS7.generateSignedData instead of 
>>> ContentSigner. Just because the ContentSigner APIs are still there 
>>> doesn't mean you have to use it in jarsigner (unless I am missing 
>>> something).
>>>
>>> --Sean
>>>
>>>> —Max
>>>>>> 在 2020年4月9日，21:27，Sean Mullan <sean.mullan at oracle.com> 写道：
>>>>> On 4/9/20 3:13 AM, Wang Weijun wrote:
>>>>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS 
>>>>>> and EdDSA. Sigh.
>>>>> Why would you need to do that if they are deprecated?
>>>>>
>>>>> --Sean
>>>>>
>>>>>> --Max
>>>>>>>> 在 2020年4月9日，01:58，Sean Mullan <sean.mullan at oracle.com> 写道：
>>>>>>> We never actually deprecated the com.sun.jarsigner package with 
>>>>>>> a forRemoval=true flag, so while it may be very low-risk to 
>>>>>>> remove these APIs, I feel that we should not remove it w/o prior 
>>>>>>> notice.
>>>>>>>
>>>>>>> I would suggest adding the forRemoval=true for this package/APIs 
>>>>>>> instead, and plan on removing it in JDK 16 or 17.
>>>>>>>
>>>>>>> I'm ok with removing the jarsigner options because the man page 
>>>>>>> already warned that they may be removed.
>>>>>>>
>>>>>>> --Sean
>>>>>>>
>>>>>>>
>>>>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>>>>>> I am thinking about removing the `jarsigner -altsigner 
>>>>>>>> -altsignerpath` options and underlying classes:
>>>>>>>>              JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>>>>>> Please review everything at:
>>>>>>>>     Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>>>>>              CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>>>>>           webrev : 
>>>>>>>> http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>>>>>> The CSR "Problem" section has more info on why it's better to 
>>>>>>>> remove it now.
>>>>>>>> Thanks,
>>>>>>>> Max
>