Bug ID: JDK-8209696 Regression manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails

Type: Bug
Component: security-libs
Sub-Component: java.security
Affected Version: 11,14,15,16

Priority: P3
Status: Resolved
Resolution: Not an Issue
OS: generic
CPU: generic

Submitted: 2018-08-15
Updated: 2021-01-22
Resolved: 2021-01-22

Other
tbdResolved

Testsuite name: Regression manual
Test name(s):sun/security/tools/jarsigner/compatibility/Compatibility.java
Product(s) tested: JDK11.0.1 b05 (64bit)
OS/architecture: Solaris 11.3 SPARCv9/Jtreg4.2b13
Reproducible: Always
Reproducible on machine: Evergreen-machine 

Actual behavior:
The case "sun/security/tools/jarsigner/compatibility/Compatibility.java"  failed automatically for lang.RuntimeException: At least one test case failed.

As agreed, we close this ticket since there were multiple type of issues reported agains this particular test. The resolution is "Not an issue" since the latest reported problem is caused by an external TSA server not longer supporting SHA-1. When using another server, the issue is not reproducible. Although, there is an actual issue with this test reported in JDK-8260286.
22-01-2021
I agree we should open a new bug and close this one. As you mentioned, there were 2 issues discussed in this bug, the first one solaris specific and the second one was failing in all platforms. That last one is not actually a bug, the failure reason is that the specific external TSA server used for testing is not supporting SHA-1 anymore (server url is passed as argument in the manual test). But, using another server the file is signed properly. Now, there is a new issue (has not been reported before) during signature verification, the test is not handling the "weak algorithm" warning introduced in early 2020 (JDK 15): https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8172404 The test only fails for that warning after JDK15 and backported versions, and passes in previous versions as expected
21-01-2021
SHA1 was disabled recently (late 2020). This test failure was reported before that. May be you are seeing this additional reason with JDK 16. Please check earlier jtr files. Can you please run this with JDK 11 and JDK 16 to see if the failure reason is same. Also, initially this issue started being solaris specific which was fixed, AFAIK. May be we should close this bug and open new one to allow SHA-1 algorithm.
21-01-2021
Inspired by the above test, the attached SigTest.java can reproduce this issue. And the attached SigTest.out is the output after running SigTest.java in that specific machine.
30-01-2019
// The following test can show the problem. When arg is 256 or 384 the verify() // results of Signature from different providers are different import java.security.KeyPair; import java.security.KeyPairGenerator; import java.security.Signature; public class T1 { static byte[] msg = new byte[100]; public static void main(String[] args) throws Exception { KeyPairGenerator g = KeyPairGenerator.getInstance("EC"); g.initialize(Integer.parseInt(args[0])); KeyPair p = g.generateKeyPair(); Signature s = Signature.getInstance("SHA512withECDSA"); s.initSign(p.getPrivate()); s.update(msg); byte[] sig = s.sign(); s = Signature.getInstance("SHA512withECDSA"); s.initVerify(p.getPublic()); s.update(msg); System.out.println(s.verify(sig)); s = Signature.getInstance("SHA512withECDSA", "SunEC"); s.initVerify(p.getPublic()); s.update(msg); System.out.println(s.verify(sig)); } }
19-01-2019
The attached test SignatureTest.java signs and verifies data with RSA and EC key algorithms and the associated signature algorithms. It covers EC key sizes 384 and 571, but cannot reproduce this issue on the specific Solaris machine.
27-11-2018
The attached test SignatureTest2.java creates a keystore with the existing certificate and private key. In this test, a Signature instance retrieves the private key and public key from the key store to do signing and verifying. But it still cannot reproduce this issue in the specific Solaris machine.
27-11-2018
If keytool doesn't use provider SunPKCS11-Solaris (via -Dsun.security.pkcs11.enable-solaris=false), it can generate EC key pairs on size 112. And If jarsigner doesn't use SunPKCS11-Solaris, the signing cases on key size 112, 256 and 384 also passed. I suppose provider SunEC should be used then.
26-11-2018
With further testing, the issue may be affected by the EC key size. The signing case in the above comment passed if EC key size is 512 and 571, but it failed on 256 and 384. If using key size 112, keytool failed with the below error: keytool error: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ATTRIBUTE_VALUE_INVALID Not sure it has something wrong with the PKCS11 on the specific Solaris machine: SunOS 5.11 11.3 sun4v sparc SUNW,Netra-T2000
26-11-2018
This issue could be reproduced by the following commands $ echo "TEST" > test $ jar cvf test.jar test $ keytool -storetype jks -genkey -keyalg EC -keysize 384 -dname CN=Test -alias test -keypass testpass -storepass testpass -keystore test.jks $ jarsigner -debug -verbose -sigalg SHA512withECDSA -keystore test.jks -storepass testpass -signedjar signedTest.jar test.jar test
26-11-2018
Because the failed cases don't use TSA, so this issue should has nothing to do with TSA service. It looks the problem is related to jar signing with SHA512withECDSA on Solaris.
23-11-2018
The attached report.zip contains more details about the test execution.
23-11-2018
updating: META-INF/MANIFEST.MF adding: META-INF/11_0_2_4.SF adding: META-INF/11_0_2_4.EC signing: test jar: beginEntry META-INF/MANIFEST.MF jar: beginEntry META-INF/11_0_2_4.SF jar: processEntry: processing block jar: beginEntry META-INF/11_0_2_4.EC jar: processEntry: processing block java.lang.SecurityException: cannot verify signature block file META-INF/11_0_2_4 at java.base/sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:296) at java.base/sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:269) at java.base/java.util.jar.JarVerifier.processEntry(JarVerifier.java:316) at java.base/java.util.jar.JarVerifier.update(JarVerifier.java:230) at java.base/java.util.jar.JarFile.initializeVerifier(JarFile.java:757) at java.base/java.util.jar.JarFile.getInputStream(JarFile.java:838) at jdk.jartool/sun.security.tools.jarsigner.Main.signJar(Main.java:1672) at jdk.jartool/sun.security.tools.jarsigner.Main.run(Main.java:269) at jdk.jartool/sun.security.tools.jarsigner.Main.main(Main.java:118) jar signed.
23-11-2018
The test passed with TSA service http://timestamp.comodoca.com/rfc3161 and jdk 11.0.2-ea+2 on solaris-sparcv9. Just closed this issue. If meet the same issue again, please re-open it. Please also check if the TSA service and network are reliable.
31-10-2018
Does this fail with earlier JDK version or a new regression only with JDK11.0.1 b05? Please try earlier version also.
20-08-2018