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 <sean.mul...@oracle.com> 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 <sean.mul...@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.mul...@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.mul...@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
