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

[sha.jiang at oracle.com]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170609/b99ce9d4/attachment.htm>