Looks good.
--Sean
On 4/10/20 8:40 AM, Weijun Wang wrote:
Please take a review at
CSR : https://bugs.openjdk.java.net/browse/JDK-8242488
webrev : http://cr.openjdk.java.net/~weijun/8242330/webrev.00/
Thanks,
Max
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
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,
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
Please take a review at
CSR : https://bugs.openjdk.java.net/browse/JDK-8242488
webrev : http://cr.openjdk.java.net/~weijun/8242330/webrev.00/
Thanks,
Max
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
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
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
Please take a review at
CSR : 8228481: Upgrade the default PKCS12 encryption/MAC algorithms
Release note : https://bugs.openjdk.java.net/browse/JDK-8242069
webrev : http://cr.openjdk.java.net/~weijun/8153005/webrev.00/
The default pkcs12 algorithms are bumped into PBE and
