Hi Andrew
Well, this code change is to make jarsigner behaviors to be consistent
with Java Plugin, that is to say, if Java Plugin allows something
jarsigner should also.
If you believe that Java Plugin's behavior itself is problematic, we can
suspend this code change for a while and focus on Java Plugin.
Thanks
Max
On 02/28/2012 10:11 PM, Xuelei Fan wrote:
I have not read the changes, just some minor comments about the description.
On Feb 26, 2012, at 11:00 PM, Weijun Wang<[email protected]> wrote:
Hi All
Please take a look at this code change:
http://cr.openjdk.java.net/~weijun/7149012/webrev.00/
Jarsigner will not print a warning if the signer cert is expired but a
timestamp shows the jar was signed before the expiration date.
Another change is that the chainNotValidated flag now does not cover
hasExpiredCert and notYetValidCert anymore. The result is that when trying to
sign (or verify) with an expired cert, instead of the duplicated and somewhat
confusing
The signer certificate has expired.
The signer's certificate chain is not validated.
warnings, user will only see
The signer certificate has expired.
It seems that we allow the singer sigh jars with expired certificate. It's
flexible, but as may not comply to the policy of certificate authority. At most
of the time, CA will not take any responsibility to expired certificate. I
know the compatibility may be the concerns, but I really think we should forbid
the sign behaviors by default, and allow the verification behaviors by default
if time stamped.
Xuelei
User will still see the chainNotValidated warning if the CertPath is not
validated because of other reasons.
On the other hand, since these 3 flags share the same exit code (4), users will
not notice the exit code change when -strict is on.
There is no regression test added to the openjdk repository because it's not easy to
generate a timestamp with an old date. I have found an old signed jar with a timestamp
and signed by a now-expired cert. I will include these binary files into the
jdk/test/closed repository and the test is a simple "jarsigner -verify -strict"
call.
Thanks
Max
-------- Original Message --------
*Change Request ID*: 7149012
*Synopsis*: jarsigner needs not warn about cert expiration if the jar has a TSA
timestamp
=== *Description* ============================================================
If the cert used to sign a jar is expired, jarsigner will print out a warning,
and if -strict is specified, exits with an error. However, if there is a TSA
timestamp attached to the jar (and the timestamp is shown to be before the
expiration), it's completely valid and jarsigner should not report any warning
or error.
