Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
Thanks. All suggestions accepted.
--Max
> On Apr 16, 2020, at 2:40 AM, Sean Mullan wrote:
>
> On 4/14/20 3:27 AM, Weijun Wang wrote:
>> After some discussion, we decide to keep the classes in JDK 15 but add a
>> `forRemoval=true` argument. Related jarsigner help screen and warning
>> message are also updated.
>> Please review everything updated at:
>> Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>
> Reviewed. I think it is probably better to flag this with an RN-Deprecated
> label since this is about marking it for removal and will show up in a
> section of the release notes about deprecation. You could check with others
> on this though.
>
>>CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>> webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.01/ (a
>> new URL!)
>
> - add 2020 date to copyright in package-info.java
>
> - Resources.java:
>
> 94 {".altsigner.class.class.name.of.an.alternative.signing.mechanism",
> 95 "[-altsigner ]class name of an alternative
> signing mechanism\n" +
> 96 "(This option has been
> deprecated and will be removed in a future release.)"},
> 97 {".altsignerpath.pathlist.location.of.an.alternative.signing.mechanism",
> 98 "[-altsignerpath ] location of an alternative
> signing mechanism\n" +
> 99 "(This option has been
> deprecated and will be removed in a future release.)"},
>
> I would change "has been deprecated" to "is deprecated" which is consistent
> with the "This.option.is.forremoval" message and seems a bit clearer.
>
> --Sean
>
>> Thanks,
>> Max
>>> On Apr 7, 2020, at 4:04 PM, 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
>>>
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
On 4/14/20 3:27 AM, Weijun Wang wrote:
After some discussion, we decide to keep the classes in JDK 15 but add a
`forRemoval=true` argument. Related jarsigner help screen and warning message
are also updated.
Please review everything updated at:
Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
Reviewed. I think it is probably better to flag this with an
RN-Deprecated label since this is about marking it for removal and will
show up in a section of the release notes about deprecation. You could
check with others on this though.
CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.01/ (a new
URL!)
- add 2020 date to copyright in package-info.java
- Resources.java:
94
{".altsigner.class.class.name.of.an.alternative.signing.mechanism",
95 "[-altsigner ]class name of an
alternative signing mechanism\n" +
96 "(This option has been
deprecated and will be removed in a future release.)"},
97
{".altsignerpath.pathlist.location.of.an.alternative.signing.mechanism",
98 "[-altsignerpath ] location of an
alternative signing mechanism\n" +
99 "(This option has been
deprecated and will be removed in a future release.)"},
I would change "has been deprecated" to "is deprecated" which is
consistent with the "This.option.is.forremoval" message and seems a bit
clearer.
--Sean
Thanks,
Max
On Apr 7, 2020, at 4:04 PM, 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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
mach5 passed. > On Apr 14, 2020, at 3:27 PM, Weijun Wang wrote: > > After some discussion, we decide to keep the classes in JDK 15 but add a > `forRemoval=true` argument. Related jarsigner help screen and warning message > are also updated. > > Please review everything updated 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.01/ (a new > URL!) > > Thanks, > Max > >> On Apr 7, 2020, at 4:04 PM, 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 >> >
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
After some discussion, we decide to keep the classes in JDK 15 but add a `forRemoval=true` argument. Related jarsigner help screen and warning message are also updated. Please review everything updated 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.01/ (a new URL!) Thanks, Max > On Apr 7, 2020, at 4:04 PM, 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 >
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
> On Apr 11, 2020, at 11:53 PM, Sean Mullan wrote: > > On 4/11/20 11:04 AM, Weijun Wang wrote: >> 2. Keep the options and update the deprecated classes to work with new >> signature algorithms. The update will likely to be 2 new methods and >> deprecating one existing. > > Not sure if I understand this option, but I assume this is about adding > RSASSA-PSS support to jarsigner. Perhaps we just delay that until JDK 16 when > you can remove the ContentSigner APIs, as it would be strange to add new > methods to a deprecated class that will be marked forRemoval. This is for both RSASSA-PSS and EdDSA, where you cannot derive the digest algorithm and signature algorithm parameters from the signature algorithm name. > > Also, why do we have to use the ContentSigner APIs for RSASSA-PSS? Couldn't > you just use internal APIs as in your webrev? That's option 1: "Remove the options. The deprecated classes become useless." --Max > > --Sean
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
On 4/11/20 11:04 AM, Weijun Wang wrote: 2. Keep the options and update the deprecated classes to work with new signature algorithms. The update will likely to be 2 new methods and deprecating one existing. Not sure if I understand this option, but I assume this is about adding RSASSA-PSS support to jarsigner. Perhaps we just delay that until JDK 16 when you can remove the ContentSigner APIs, as it would be strange to add new methods to a deprecated class that will be marked forRemoval. Also, why do we have to use the ContentSigner APIs for RSASSA-PSS? Couldn't you just use internal APIs as in your webrev? --Sean
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
Today if you call "jarsigner -altsigner", it works but shows a warning: This option is deprecated: -altsigner I think we have several solutions now: 1. Remove the options. The deprecated classes become useless. 2. Keep the options and update the deprecated classes to work with new signature algorithms. The update will likely to be 2 new methods and deprecating one existing. Anyway, we will add a forRemoval=true to the classes. Of course, if we can remove all of them, that will be very clean. I'll write a mail asking Joe and Stuart tomorrow. It's 11pm here. --Max > On Apr 11, 2020, at 10:56 PM, Alan Bateman wrote: > > On 11/04/2020 15:41, Weijun Wang wrote: >> The options were already deprecated long ago: >> >> $ $J14/bin/jarsigner >> Usage: jarsigner [options] jar-file alias >>jarsigner -verify [options] jar-file [alias...] >> ... >> >> [-altsigner ]class name of an alternative signing mechanism >> (This option has been deprecated.) >> >> [-altsignerpath ] location of an alternative signing mechanism >> (This option has been deprecated.) >> ... >> >> and they are listed in a "Deprecated Options" section in the tooldoc with >> "might be removed in a future JDK release". >> >> The only problem is I forgot to add a forRemoval=true argument to the >> @Deprecated annotation of the classes. >> > I think the next step is to terminally deprecate the API, this means adding > forRemoval=true to create awareness at compile-time. You can then remove in > some future release. You can use the opportunity to add a warning to the > jarsigner tool so that someone using these options gets a warning and knows > it will be removed in the future (they might not see deprecation notice in > the usage/help output). > > -Alan
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
On 11/04/2020 15:41, Weijun Wang wrote: The options were already deprecated long ago: $ $J14/bin/jarsigner Usage: jarsigner [options] jar-file alias jarsigner -verify [options] jar-file [alias...] ... [-altsigner ]class name of an alternative signing mechanism (This option has been deprecated.) [-altsignerpath ] location of an alternative signing mechanism (This option has been deprecated.) ... and they are listed in a "Deprecated Options" section in the tooldoc with "might be removed in a future JDK release". The only problem is I forgot to add a forRemoval=true argument to the @Deprecated annotation of the classes. I think the next step is to terminally deprecate the API, this means adding forRemoval=true to create awareness at compile-time. You can then remove in some future release. You can use the opportunity to add a warning to the jarsigner tool so that someone using these options gets a warning and knows it will be removed in the future (they might not see deprecation notice in the usage/help output). -Alan
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
The options were already deprecated long ago: $ $J14/bin/jarsigner Usage: jarsigner [options] jar-file alias jarsigner -verify [options] jar-file [alias...] ... [-altsigner ]class name of an alternative signing mechanism (This option has been deprecated.) [-altsignerpath ] location of an alternative signing mechanism (This option has been deprecated.) ... and they are listed in a "Deprecated Options" section in the tooldoc with "might be removed in a future JDK release". The only problem is I forgot to add a forRemoval=true argument to the @Deprecated annotation of the classes. --Max > On Apr 11, 2020, at 10:20 PM, Alan Bateman wrote: > > On 11/04/2020 14:20, Sean Mullan wrote: >> 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. >> > There is a JDK-specific API and command line options on the table here. > Removing these without notice may surprise some. For the APIs then you could > terminally deprecate them in JDK 15 and remove them in a future release. I > don't think JEP 277 has been updated to provide guidance in the context of > the new release cadence so use your best judgement (JDK 16 might be too soon > to remove). As regards the CLI options then you could add a warning to > jarsigner so that anyone using this tool with existing content signers > (compiled for JDK 8 for example) has some chance of seeing that the options > will be going away in the future. > > -Alan.
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
On 11/04/2020 14:20, Sean Mullan wrote: 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. There is a JDK-specific API and command line options on the table here. Removing these without notice may surprise some. For the APIs then you could terminally deprecate them in JDK 15 and remove them in a future release. I don't think JEP 277 has been updated to provide guidance in the context of the new release cadence so use your best judgement (JDK 16 might be too soon to remove). As regards the CLI options then you could add a warning to jarsigner so that anyone using this tool with existing content signers (compiled for JDK 8 for example) has some chance of seeing that the options will be going away in the future. -Alan.
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
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 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 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 写道：
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 写道：
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 写道：
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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
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.
--Max
> On Apr 11, 2020, at 5:44 PM, Peter Levart 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 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 写道：
>>
>> 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 写道：
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 写道：
>> 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:
>>>
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
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 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 写道：
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 写道：
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 写道：
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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
I simplified the issue. In fact, for RSASSA-PSS, we also need to pass the PSSParameters itself to the ContentSigner because it also needs to be encoded in SignerInfo. So another method getSignatureAlgorithmParameters() is needed. Or, to make things general, we can deprecate getSignatureAlgorithm() and add 2 new methods getSignatureAlgorithmIdentifiers() and getDigestAlgorithmIdentifiers() --Max > On Apr 10, 2020, at 10:02 PM, Weijun Wang wrote: > > Currently, ContentSignerParameters has an interface method > getSignatureAlgorithm(), the return value (Ex: SHA1withRSA) is then used by > the ContentSigner to extract the digest algorithm (SHA1) to be put into a > PKCS7 SignerInfo [1]. > > But the new algorithms are not named this way. For RSASSA-PSS, the digest > algorithm is inside its PSSParameters. For EdDSA, in the private key (which > tells if it's Ed25519 or Ed448). > > So, we'll need a new interface method getDigestAlgorithm(). > > It's awkward to add a new method to a deprecated interface. > > --Max > > [1] https://tools.ietf.org/html/rfc5652#section-5.3 > >> On Apr 10, 2020, at 8:52 PM, Sean Mullan wrote: >> >> 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 写道： > > 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 写道： >>> 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 写道： > 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 >
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
Currently, ContentSignerParameters has an interface method getSignatureAlgorithm(), the return value (Ex: SHA1withRSA) is then used by the ContentSigner to extract the digest algorithm (SHA1) to be put into a PKCS7 SignerInfo [1]. But the new algorithms are not named this way. For RSASSA-PSS, the digest algorithm is inside its PSSParameters. For EdDSA, in the private key (which tells if it's Ed25519 or Ed448). So, we'll need a new interface method getDigestAlgorithm(). It's awkward to add a new method to a deprecated interface. --Max [1] https://tools.ietf.org/html/rfc5652#section-5.3 > On Apr 10, 2020, at 8:52 PM, Sean Mullan wrote: > > 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 写道： 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 写道： >> 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 写道： 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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
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 写道： 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 写道： 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 写道： 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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
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
> On Apr 10, 2020, at 5:22 PM, Peter Levart 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 写道：
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 写道：
>> 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 写道：
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
>>
>
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
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 写道： 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 写道： 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 写道： 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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
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 写道： 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 写道： 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 写道： 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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
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 写道： > > 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 写道： >>> >>> 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 写道： > > 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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
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 写道： 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 写道： 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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
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. —Max > 在 2020年4月9日，21:27，Sean Mullan 写道： > > 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 写道： >>> >>> 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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
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 写道： 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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh. --Max > 在 2020年4月9日，01:58，Sean Mullan 写道： > > 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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
I added my name to the CSR. > On Apr 7, 2020, at 6:41 PM, Weijun Wang wrote: > > Can you please add your name as a CSR reviewer? > > Thanks, > Max > >> On Apr 8, 2020, at 9:25 AM, Xuelei Fan wrote: >> >> +1. >> >> Xuelei >> >>> On 4/7/2020 6:18 PM, Hai-May Chao wrote: >>> Hi Max, >>> Changes look good to me. >>> Is there a man page bug being filed for this? >>> Thanks, >>> Hai-May On Apr 7, 2020, at 1: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 >
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
Can you please add your name as a CSR reviewer? Thanks, Max > On Apr 8, 2020, at 9:25 AM, Xuelei Fan wrote: > > +1. > > Xuelei > > On 4/7/2020 6:18 PM, Hai-May Chao wrote: >> Hi Max, >> Changes look good to me. >> Is there a man page bug being filed for this? >> Thanks, >> Hai-May >>> On Apr 7, 2020, at 1: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 >>>
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
+1. Xuelei On 4/7/2020 6:18 PM, Hai-May Chao wrote: Hi Max, Changes look good to me. Is there a man page bug being filed for this? Thanks, Hai-May On Apr 7, 2020, at 1: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
Re: RFR 8242260: Remove customizable ContentSigner from jarsigner
Hi Max, Changes look good to me. Is there a man page bug being filed for this? Thanks, Hai-May > On Apr 7, 2020, at 1: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 >
RFR 8242260: Remove customizable ContentSigner from jarsigner
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
