RFR JDK-8179614: Test for jarsigner on verifying jars that are signed and timestamped by other JDK releases

[Weijun Wang]

On 06/09/2017 09:25 PM, sha.jiang at oracle.com wrote:
> Hi Max,
> 
> On 09/06/2017 20:05, Weijun Wang wrote:
>> The test can be more friendly with default values.
>>
>> For example, in createCertificates(), you can generate certs that use 
>> default sigalg and keysize (i.e. without specifying -siglag and 
>> -keysize), and give them aliases with "default" or "null" inside.
>>
>> And in jar signing when signing with one -sigalg you can also choose 
>> cert generated with different or default sigalgs.
> I supposed this test just focus on signed jar verifying, but not 
> certificate creating and jar signing. So, I'm not sure such cases are 
> necessary.

Well sometimes a test can do many things. If you only care about jar 
verification, why bother creating certs with different digest algorithms?

On the other hand, if you do care about more, then in

  338     // If the digest algorithm is not specified, then it
  339     // uses certificate with SHA256 digest and 1024 key
  340     // size.
  341     if (digestAlgorithm == DEFAULT) {
  342         certDigest = SHA256;
  343         certKeySize = 1024;
  344     }

it seems a little awkward to hardcode the algorithm and keysize. If 
signing is using a default algorithm, it seems natural to use the cert 
that was generated with a default algorithm. In fact, this test case is 
quite useful that it ensures our different tools are using the same (or 
at least interoperable) default algorithms.

--Max

>>
>> BTW, I remember certain pairs of -keysize and -sigalg do not work 
>> together. For example, 1024 bit of DSA key cannot be used with 
>> SHA512withDSA signature algorithm. Have you noticed it?
> It looks SHA512withDSA is not supported yet.
> I was using JDK10 build 10. When the test tried to create certificate 
> with -keyalg DSA -sigalg SHA512withDSA -keysize 1024, the below error 
> raised:
> keytool error: java.security.NoSuchAlgorithmException: unrecognized 
> algorithm name: SHA512withDSA
> 
> If used -keyalg DSA -sigalg SHA1withDSA -keysize 2048, the error was:
> keytool error: java.security.InvalidKeyException: The security strength 
> of SHA-1 digest algorithm is not sufficient for this key size
> 
> Again, this test focus on signed jar verifying. If some problems are 
> raised on certificate creating or jar signing, the associated verifying 
> cases will be ignored.
> 
> Best regards,
> John Jiang
>>
>> Thanks
>> Max
>>
>>
>> On 06/09/2017 04:44 PM, sha.jiang at oracle.com wrote:
>>> Hi Sean and Max,
>>> Thanks for your comments.
>>> Please review the updated webrev: 
>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.01/
>>>
>>> The test has been modified significantly. The main points are:
>>> 1. Adds cases on EC. Now the test supports key algorithms RSA, DSA 
>>> and EC.
>>> 2. Adds cases on SHA-512. Now the test supports digest algorithms 
>>> SHA-1, SHA-256 and SHA-512.
>>> 3. Adds cases on key size. Exactly, [384, 571] for EC, [1024, 2048] 
>>> for RSA and DSA.
>>> 4. Adds cases on default signature algorithm. Now the test report can 
>>> display the default algorithmat column [Signature Algorithm].
>>> 5. Adds property -Djava.security.egd=file:/dev/./urandom for keytool 
>>> and jarsigner commands.
>>> 6. Create a separated application, JdkUtils.java, to determine the 
>>> JDK build version (java.runtime.version) and check if a signature 
>>> algorithm is supported by a JDK.
>>> 7. Introduces a new property, named javaSecurityFile, for allowing 
>>> users to specify alternative java security properties file.
>>> 8. Renames report column [Cert Type] to [Certificate]. This column 
>>> displays the certificate identifiers, which is a combination of key 
>>> algorithm, digest algorithm, key size and expired mark (if any).
>>> 9. The test summary also be updated accordingly.
>>>
>>> Best regards,
>>> John Jiang
>>>
>>>
>>> On 07/06/2017 23:11, Sean Mullan wrote:
>>>> On 6/6/17 9:14 PM, sha.jiang at oracle.com wrote:
>>>>> Hi Sean,
>>>>>
>>>>> On 07/06/2017 04:27, Sean Mullan wrote:
>>>>>> Hi John,
>>>>>>
>>>>>> This looks like a very useful test. I have not gone through all of 
>>>>>> the code, but here are a few comments for now until I have more time:
>>>>>>
>>>>>> - add tests for EC keys
>>>>>> - add tests for SHA-512 variants of the signature algorithms
>>>>>> - add tests for larger key sizes (ex: 2048 for DSA/RSA)
>>>>>> - you can use the diamond operator <> in various places
>>>>>> - might be more compact if jdkList() used Files.lines() to parse 
>>>>>> the file into a stream then an array
>>>>> I did consider about the above two points. Because the test will be 
>>>>> backported to JDK 6, so I only used the features those supported by 
>>>>> JDK 6.
>>>>> I supposed that would make the backport easier. Does it make sense?
>>>>
>>>> Yes, that makes sense.
>>>>
>>>> --Sean
>>>>
>>>>>
>>>>> Best regards,
>>>>> John Jiang
>>>>>> - did you consider using the jarsigner API 
>>>>>> (jdk.security.jarsigner) instead of the command-line? I think this 
>>>>>> would be better (if possible) and it would give us some more tests 
>>>>>> of that API.
>>>>>>
>>>>>> --Sean
>>>>>>
>>>>>> On 6/5/17 6:31 AM, sha.jiang at oracle.com wrote:
>>>>>>> Hi,
>>>>>>> Please review this manual test for checking if a jar, which is 
>>>>>>> signed and timestamped by a JDK build, could be verified by other 
>>>>>>> JDK builds.
>>>>>>> It also can be used to check if the default timestamp digest 
>>>>>>> algorithm on signing is SHA-256.
>>>>>>> For more details, please look through the test summary.
>>>>>>>
>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8179614
>>>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8179614/webrev.00/
>>>>>>>
>>>>>>> Best regards,
>>>>>>> John Jiang
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>