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.ji...@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.ji...@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.ji...@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
