On Feb 28, 2012, at 6:19 AM, Weijun Wang <[email protected]> wrote:
> 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. > Please don't. My previous comment only a suggestion to rethink about the signer's behaviors. It may be a potential enhancement. Please go on with the bug fix. BTW, I thought java plugin only do validation. It also do jobs to sign something, is it? Thanks, Xuelei > 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. >>>
