code review request: 7149012: jarsigner needs not warn about cert expiration if the jar has a TSA timestamp

[Xuelei Fan]

Looks fine to me.

Thanks for the update.

Xuelei

On Mar 2, 2012, at 2:29 AM, Weijun Wang <weijun.wang at oracle.com> wrote:

> 
> 
> On 02/29/2012 11:32 PM, Xuelei Fan wrote:
>> So far, I only have a very minor comment:
>> 
>> The block from line 875 to 880 is a little overlapped with lines 884 to
>> 889. Is it possible to improve the code?
> 
> A flag added:
> 
>  http://cr.openjdk.java.net/~weijun/7149012/webrev.01/
> 
>> 
>> I'm not sure whether it is better to not-show the warning for
>> timestamped signatures with expired certificates. Need more time to
> 
> In this case, jarsigner would show
> 
>      [entry was signed on 10/24/03 4:18 PM]
>      [certificate is valid from 10/24/03 5:29 AM to 10/25/03 5:29 AM]
> 
> if -verbose -certs is specified, please note the *was* word. It just does not print a warning. Except for the "Will Expire in 6 Months" one, most warnings will be actual errors when loaded in Java Plug-in.
> 
>> understand the scenarios of time-stamping in JarSigner. Does the
>> validity of TSA certificate is also checked?
> 
> Yes, during the verification of the jar file, its info is included in the CodeSigner class.
> 
> Thanks
> Max
> 
>> 
>> Xuelei
>> 
>> On 2/27/2012 3:00 PM, Weijun Wang 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.
>>> 
>>> 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.
>>> 
>>