RFR 8242260: Remove customizable ContentSigner from jarsigner

Sat Apr 11 13:20:51 UTC 2020

On 4/11/20 6:31 AM, Weijun Wang wrote:
> If the rule is that an API must be labeled forRemoval=true before it's really removed, then I cannot remove them in JDK 15.

Here is what JEP 277 [1] says:

    The following elements are to be added to the java.lang.Deprecated annotation type:

    A method forRemoval() returning a boolean. If true, it means that this
    API element is earmarked for removal in a future release. If false, the
    API element is deprecated, but there is currently no intention to remove
    it in a future release. The default value of this element is false.

Since these are JDK and not standard SE APIs, maybe we don't have to 
abide by that, but I think as a best practice we probably should. You 
could check with Joe Darcy and Stuart Marks if you want to be more sure.

--Sean

[1] https://openjdk.java.net/jeps/277

>
> --Max
>
>> On Apr 11, 2020, at 5:44 PM, Peter Levart <peter.levart at gmail.com> wrote:
>>
>>
>>
>> On 4/10/20 11:45 AM, Weijun Wang wrote:
>>> Hi Peter,
>>>
>>> This is awkward but I've seen method that is marked deprecated for removal which simply throws an UnsupportedOperationException.
>>>
>>> Suppose someone has an "enhanced" jarsigner that is also calling the JarSigner API. It might also support customized ContentSigner but is also used by no one. If the classes were removed the tool will not compile. If the classes remain but JarSigner no longer uses it, it will simply throws an UOE which is harmless to most people.
>>>
>>> Maybe the tool maintainer has already added "@SuppressWarnings("deprecated")", but this time they will see a new warning on "[removal]", and they will know they need to remove it within a year.
>>>
>>> --Max
>> Hi Max,
>>
>> What I was trying to say is that even if you remove ContentSigner class(es) from JDK 15, users will still be able to compile either the special "enhanced" jarsigner or the ContentSigner implementations if they use -release 14 option.  They will just not be able to run the "enhanced" jarsigner with JDK 15. So removing a class from JDK 15 is not so bad as it was before the -release option was available. At least from the standpoint of compilation. So it makes a little difference if you remove the classes or not when you also remove the options to use/run the classes with jarsigner. What you choose is of course up to you. I see Sean is suggesting that you keep the options in the jarsigner for JDK 15.
>>
>> Regards, Peter
>>
>>>> On Apr 10, 2020, at 5:22 PM, Peter Levart <peter.levart at gmail.com> wrote:
>>>>
>>>> Which brings me to this...
>>>>
>>>> If it is a requirement to use -release option to compile ContentSigner implementation class in order for them to be usable (with some older release of jarsigner), then ContentSigner classes could as well be removed from the JDK 15 API because their signature will still be available to the javac with appropriate -release 14 or older option. So compilation would still succeed.
>>>>
>>>> Peter
>>>>
>>>> On 4/10/20 11: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200411/4537cf58/attachment.htm>