On 05/17/2017 04:01 AM, Sean Mullan wrote:
* 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.
Or I can initialize ts to be null.
* Main.java
[271-2] Perhaps you should use a different exit code to distinguish it
from an invalid signer chain?
I can use 64. Although I am not quite sure of the usefulness of
difference exit codes now.
[1064-6] Not sure I understand this block of code. How can a jar have an
invalid timestamp if -tsa was not specified?
This is in verification. Because of weak algorithms (and maybe more),
it's possible that the API does not show there is a timestamp
(noTimestamp) but the PKCS7 block file has a tsToken
(hasTimestampBlock). I'd like to show different warnings here.
[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.
Yes, we can.
BTW, I am thinking of more changes. jarsigner had so many different
warnings (cert expired, cert usage...) because it was not using
sun.security.validator.Validator before and checked these all by its
own. It should rely on Validator but keep showing the warnings for
compatibility. The lines on 1992-2012 was added to deliberately avoid
showing both these "legacy" warnings and validation warnings at the same
time. I'd prefer to remove these lines. As long as the exit code does
not change (they are all the same for signer certs, 4), showing an extra
warning line is not harmful.
Thanks
Max
--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
