* Resources.java
[278] s/includes/include/
* SignatureFileVerifier
[728] setting ts to null in the catch block seems a bit ugly. Maybe it
would be better to refactor that code into a static method that returns
a valid Timestamp or null if not.
* Main.java
[271-2] Perhaps you should use a different exit code to distinguish it
from an invalid signer chain?
[1064-6] Not sure I understand this block of code. How can a jar have an
invalid timestamp if -tsa was not specified?
[1546-7] TODO item - Why can't we do this? We need to warn the user if
they sign a JAR and the TSA chain is invalid so they know what to expect
and are not surprised when it stops working the day after the signer's
cert expires.
--Sean
On 5/10/17 7:36 PM, Weijun Wang wrote:
Ping again.
On 04/12/2017 11:52 PM, Weijun Wang wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8166222/webrev.00/
The major code change is inside SignatureFileVerifier.java. Now if the
timestamp on a signed jar is invalid (For example, using a weak
algorithm now disabled), the jar file will be treated as a signed jar
without a timestamp. Before this change, it was treated unsigned.
In jarsigner/Main.java, I also add a line to validate the TSA cert
chain. If not validated, a warning will be shown which is similar to the
one when signer cert chain is not validated. If -strict is on, exit code
will change too.
I also make a small change at
http://cr.openjdk.java.net/~weijun/8166222/root/webrev.00/
The executeCommand() method shows more info (mainly stdout and stderr
outputs) than executeProcess().
Because of the behavior change and new warnings, this change will need a
Compatibility and Specification Review (CSR). At the moment, please
review the code change first.
Thanks
Max
