RFR JDK-8179614: Test for jarsigner on verifying jars that are signed and timestamped by other JDK releases
Sean Mullan
sean.mullan at oracle.com
Tue Aug 15 17:34:15 UTC 2017
Hi John,
You should add a copyright to the README. Otherwise, this update looks good.
--Sean
On 8/14/17 11:52 PM, sha.jiang at oracle.com wrote:
> Hi,
> The webrev [1] is updated on the following points:
> 1. It allows TSA URL to append a set of supported digest algorithms. If
> a TSA URL doesn't append the digests parameter, it means that the TSA
> supports SHA-1, SHA-256 and SHA-512.
> 2. EC cases are excluded for JDK 6.
> 3. Certificates are generated by the signer JDKs themselves respectively.
> 4. jarsigner uses option "-debug".
> 5. Test mode "strict" is removed.
>
> [1] http://cr.openjdk.java.net/~jjiang/8179614/webrev.11/
>
> Best regards,
> John Jiang
>
>
> On 14/07/2017 15:11, sha.jiang at oracle.com wrote:
>>
>> Hi,
>> Please review the latest webrev at:
>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.09/
>> This test has been updated significantly. It removes useless case
>> combinations, and generates reports in HTML. For more details, please
>> look through the test summary.
>>
>> Best regards,
>> John Jiang
>>
>> On 13/06/2017 23:47, sha.jiang at oracle.com wrote:
>>> Sean and Max,
>>> Please review this updated webrev:
>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.03/
>>>
>>> The main changes are:
>>> 1. It provides two new properties, tsaList and tsaListFile, for
>>> specifying a list of TSA services.
>>> And a new report column [TSA] is introduced. This column just display
>>> the TSA indices and all of TSA services are displayed at the top of
>>> the report.
>>> 2. If property strict is true, the cases on failed signing are not
>>> ignored. They still be listed in the test report, and the status of
>>> verifying are NONE.
>>>
>>> Best regards,
>>> John Jiang
>>>
>>> On 13/06/2017 06:51, sha.jiang at oracle.com wrote:
>>>> 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