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

[sha.jiang at oracle.com]

Hi Max,
Would you like to review the updated webrev: 
http://cr.openjdk.java.net/~jjiang/8179614/webrev.02/
It can create certificate without -sigalg and -keysize, and jar signing 
also can use this certificate.

Best regards,
John Jiang

On 09/06/2017 22:04, Weijun Wang wrote:
>
> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>