<html><head></head><body><div>Hi Max,</div><div><br></div><div>Yes, you are right. I confused it with an invocation of Compatibility test I imagine should be done (maybe already is) like the previously existing one for TSA compatibility. See some related mails below. Invoking SignTwice with only the current jdk does not actually verify any kind of compatibility in between different JDK versions and might possibly even be skipped altogether. I thought of it as a template for how to call it with several JDKs.</div><div><br></div><div>Regards,</div><div>Philipp</div><div><br></div><div><br></div><div><br></div><div><br></div><div><div><div><b>Date</b>: Sun, 09 Jun 2019 12:05:47 +0200</div><div><b>Subject</b>: Re: Jarsigner compatibility issue invalidating existing signatures</div><div><b>To</b>: Weijun Wang <<a href="mailto:Weijun%20Wang%20%3cweijun.wang@oracle.com%3e">weijun.wang@oracle.com</a>></div><div><b>From</b>: Philipp Kunz <<a href="mailto:Philipp%20Kunz%20%3cphilipp.kunz@paratix.ch%3e">philipp.kunz@paratix.ch</a>></div><blockquote type="cite" style="white-space: normal;"><div>Hi Max,</div><div><br></div><div>Bug 8217375 is about compatibility between different jdk versions and cannot easily be tested inside just one jdk version like most other bugs. To get a really meaningful test I figure either lots of signed jar files have to be checked in, or the code that is changed and was used to sign jars has to be moved into the tests, or the current test uses previous jdk versions to produce and verify signed jars. The last option is the one I chose to prefer and I found that Compatibility test is a very close match I considered a pretty good fit.</div><div><br></div><div>Rather than extending Compatibility test, we could as well create some similar new test, but in my opinion it would duplicate too much. Compatibility test already comes with a list of previous jdks which can be re-used to verify inter-jdk-version signature compatibility. I would not opt to build up another such a configuration prerequisite and would rather re-use that existing infrastructure.</div><div><br></div><div>I already got quite an impression of the time it takes even with a small number of jdks. This is why I added new parameters to run the test with, all of which with the idea to default to values resulting in the previous behavior. If I did everything right, no-one would or should even notice the difference when running Compatibility with the same parameters as before.</div><div><br></div><div>Eventually I suggest that more tests are run which involve combinations of different jdk versions and that will sure add some time to process. Not all possible combinations of different parameters will have to be actually tested. For example I don't see necessity to try all possible combinations of TSA digests and signature algorithms because I consider them independent. What exactly should be tested is probably worth to discuss in more detail.</div><div><br></div><div>I don't currently have an updated version of the fix but I'll be glad to provide one with the first consent how to update it.</div><div>BTW, did you not post your message to the mailing list intentionally?</div><div><br></div><div>Regards,</div><div>Philipp</div></blockquote><br></div><div><br></div></div><div><div><b>Date</b>: Tue, 11 Jun 2019 08:41:52 +0200</div><div><b>Subject</b>: Re: Jarsigner compatibility issue invalidating existing signatures</div><div><b>To</b>: Weijun Wang <<a href="mailto:Weijun%20Wang%20%3cweijun.wang@oracle.com%3e">weijun.wang@oracle.com</a>></div><div><b>From</b>: Philipp Kunz <<a href="mailto:Philipp%20Kunz%20%3cphilipp.kunz@paratix.ch%3e">philipp.kunz@paratix.ch</a>></div><blockquote type="cite"><div>Hi Max,</div><div><br></div><div>In any case I prefer to include the change to Compatibility. I don't know if my role as a contributor would entitle me to insist but I certainly welcome if you could ask Compatibility's reviewer and maintainer. The P3 priority it got might help.</div><div><br></div><div>On the other hand, it might be feasible to cover those cases with some binary jars checked into the tests. I see it as a lesser desirable alternative but it might work. I'm still thinking about how these tests should look like in detail.</div><div><br></div><div>Regards,</div><div>Philipp</div></blockquote></div><div><br></div><div><br></div><div><br></div><div><div><b>Date</b>: Thu, 23 May 2019 09:49:02 +0800</div><div><b>Subject</b>: Re: Jarsigner compatibility issue invalidating existing signatures</div><div><b>To</b>: Philipp Kunz <<a href="mailto:Philipp%20Kunz%20%3cphilipp.kunz@paratix.ch%3e">philipp.kunz@paratix.ch</a>></div><div><b>From</b>: Weijun Wang <<a href="mailto:Weijun%20Wang%20%3cweijun.wang@oracle.com%3e">weijun.wang@oracle.com</a>></div><blockquote type="cite" style="white-space: normal;"><pre>Hi Philipp,
...
Is it necessary to update Compatibility.java? This test is maintained by SQE and they run it with a script internally. The test is already spending a lot of time and I do not want to add more.
...
Thanks,
Max</pre></blockquote></div><div><br></div><div><br></div><div><br></div><div>On Mon, 2019-07-29 at 09:43 +0800, Weijun Wang wrote:</div><blockquote type="cite"><pre>
<blockquote type="cite">
On Jul 28, 2019, at 10:23 PM, Philipp Kunz <<a href="mailto:philipp.kunz@paratix.ch">philipp.kunz@paratix.ch</a>> wrote:
Hi Max,
Glad to see SignTwice being taken from ProblemList. Is it working now with the timeout added or does it still fail on windows?
</blockquote>
It hasn't failed in the last few days.
<blockquote type="cite">
<blockquote type="cite">
I just ran a test job: SignTwice.java failed on Windows with `failed to clean up files after test`. Most likely a file is not closed.
</blockquote>
For the key algs, "-DkeyAlgs=EC;" or "-DkeyAlgs=EC" might be shorter for the same effect, but "-DkeyAlgs=EC;0" is all right as well.
However, "-DdigestAlgs=SHA-256" will (far as I remember) not result in a digest that exceeds the maximum manifest line width in its encoded form as a base64 string and makes a difference. I strongly suggest to keep "-DdigestAlgs=SHA-512" or any other digest algorithm that tests line breaking of digests in signed jar file manifests.
</blockquote>
OK, I'll revert it some day, maybe as a part of JDK-8228456.
However, I believe that since SignTwice always uses the same JDK to sign and verify, the line width issue will not be a problem itself, right?
Thanks,
Max
<blockquote type="cite">
Regards,
Philipp
On Tue, 2019-07-23 at 14:28 +0800, Weijun Wang wrote:
<blockquote type="cite">
Please review the patch below. This test signs the same jar multiple times. It's mainly about making sure the manifest and signature file can be updated correctly. There is no need to try different key algorithms. We can also use a faster digest algorithm.
Thanks,
Max
diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -661,7 +661,6 @@
sun/security/tools/keytool/KeyToolTest.java 8224644 solaris-all
sun/security/tools/keytool/WeakAlg.java 8224644 solaris-all
-sun/security/tools/jarsigner/compatibility/SignTwice.java 8228341 windows-all
sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java 8026393 generic-all
javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java 8212096 generic-all
diff --git a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java
--- a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java
+++ b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.java
@@ -36,7 +36,7 @@
* @test
* @library /test/lib ../warnings
* @compile Compatibility.java
- * @run main/othervm
+ * @run main/othervm/timeout=600
* -Djava.security.properties=./java.security
* -Duser.language=en
* -Duser.country=US
@@ -46,8 +46,8 @@
* -DtestComprehensiveJarContents=true
* -DtestJarUpdate=true
* -Dstrict=true
- * -DkeyAlgs=EC;#RSA;#DSA;
- * -DdigestAlgs=SHA-512
+ * -DkeyAlgs=EC;0
+ * -DdigestAlgs=SHA-256
* SignTwice
*/
public class SignTwice {
</blockquote>
</blockquote>
</pre></blockquote><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>