RFR JDK-8179614: Test for jarsigner on verifying jars that are signed and timestamped by other JDK releases
sha.jiang at oracle.com
sha.jiang at oracle.com
Mon Jun 12 22:51:40 UTC 2017
Hi Max,
On 12/06/2017 17:29, Weijun Wang wrote:
> Great. Only 2 questions:
>
> 459 // Return key sizes according to the specified key algorithm.
> 460 private static int[] keySizes(String digestAlgorithm, String
> keyAlgorithm) {
> 461 if (digestAlgorithm == DEFAULT) {
> 462 return new int[] { 0 };
> 463 }
> 464
> 465 if (keyAlgorithm == RSA || keyAlgorithm == DSA) {
> 466 return new int[] { 1024, 2048 };
> 467 } else if (keyAlgorithm == EC) {
> 468 return new int[] { 384, 571 };
> 469 }
> 470
> 471 return null;
> 472 }
>
> Why is keysize dependent on digestalg? I mean, is it possible to
> always return {1024,2048,0} and {384,571,0}?
Get it, thanks!
>
> 379 // If signing fails, the following verifying has to
> 380 // be ignored.
> 381 if (signingStatus == STATUS.ERROR) {
> 382 continue;
> 383 }
>
> Now that you've already checked sigalg support earlier in what cases
> it could go wrong here?
Jar signing still could fail. For example, TSA service is unavailable.
Best regards,
John Jiang
>
> Thanks
> Max
>
> On 06/12/2017 03:20 PM, sha.jiang at oracle.com wrote:
>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the security-dev
mailing list