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

[Weijun Wang]

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.

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?

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
>>>>>
>>>>
>>>
>>
>