70758 - signtool fails on Windows 2000, returns still 0

Status: RESOLVED FIXED

(NSS :: Tools, defect, P2)

Description

[Sonja Mirtitsch]

The QA scripts (tools.sh) do not recognize a failure because the returncode is
still 0, but the output indicates a problem. I assume the failure is related to
a previous failure of pk12util

====================================================================
tools.sh: Signing a set of files ----------------------------
signtool -Z nojs.jar -d ../alicedir -p "nss" -k objsigner \
         ../tools/html
using certificate directory: ../alicedir
Generating ../tools/html/META-INF/manifest.mf file..
--> sign.html
adding ../tools/html/sign.html to nojs.jar...(deflated 16%)
--> signjs.html
adding ../tools/html/signjs.html to nojs.jar...(deflated 20%)
Generating zigbert.sf file..
adding ../tools/html/META-INF/manifest.mf to nojs.jar...(deflated 30%)
adding ../tools/html/META-INF/zigbert.sf to nojs.jar...(deflated 36%)
adding ../tools/html/META-INF/zigbert.rsa to nojs.jar...(deflated 33%)
tree "../tools/html" signed successfully
tools.sh: Listing signed files in jar ----------------------
signtool -w nojs.jar -d ../alicedir
using certificate directory: ../alicedir
NOTE -- "nojs.jar" archive DID NOT PASS crypto verification.
  (reported reason: Corrupt JAR file)


Signer information:

tools.sh: Show who signed jar ------------------------------
signtool -w nojs.jar -d ../alicedir
using certificate directory: ../alicedir
NOTE -- "nojs.jar" archive DID NOT PASS crypto verification.
  (reported reason: Corrupt JAR file)


Signer information:
====================================================================
This output was generatet on NT and seems to be the correct behavior
====================================================================
tools.sh: Signing a set of files ----------------------------
signtool -Z nojs.jar -d ../alicedir -p "nss" -k objsigner \
         ../tools/html
using certificate directory: ../alicedir
Generating ../tools/html/META-INF/manifest.mf file..
--> sign.html
adding ../tools/html/sign.html to nojs.jar...(deflated 9%)
--> signjs.html
adding ../tools/html/signjs.html to nojs.jar...(deflated 20%)
Generating zigbert.sf file..
adding ../tools/html/META-INF/manifest.mf to nojs.jar...(deflated 30%)
adding ../tools/html/META-INF/zigbert.sf to nojs.jar...(deflated 36%)
adding ../tools/html/META-INF/zigbert.rsa to nojs.jar...(deflated 33%)
tree "../tools/html" signed successfully
tools.sh: Listing signed files in jar ----------------------
signtool -w nojs.jar -d ../alicedir
using certificate directory: ../alicedir

Signer information:

nickname: objsigner
subject name: CN=TEST, O=MOZ, OU=NSS, ST=NY, C=US, UID=liz, E=[e-mail]
issuer name: CN=TEST, O=MOZ, OU=NSS, ST=NY, C=US, UID=liz, E=[e-mail]
tools.sh: Show who signed jar ------------------------------
signtool -w nojs.jar -d ../alicedir
using certificate directory: ../alicedir

Signer information:

nickname: objsigner
subject name: CN=TEST, O=MOZ, OU=NSS, ST=NY, C=US, UID=liz, E=[e-mail]
issuer name: CN=TEST, O=MOZ, OU=NSS, ST=NY, C=US, UID=liz, E=[e-mail]

Comment 1

[Sonja Mirtitsch]

Attachment: output.log, greasybear, WinNT build OPT

Comment 2

[Sonja Mirtitsch]

Attachment: results.html

Comment 3

[Sonja Mirtitsch]

forgot: Problem not seen on Win95 build, only on NT build, clio same behavior,
SonjaNT no failures seen

Comment 4

[theroland]

Have the same problem on win2000.
signtool only works if I'm in the same directory as it
and I give the full path to the source ex:

S:\>c:\release1.7\build\applets\signtool13winnt40\signtool.exe -d c:\release1.7\
build\applets\signtool13winnt40\ -k"mykey" -Z Import.jar  
c:\release1.7\classes\jars

will produce a valid jar file. but:

S:\>build\applets\signtool13winnt40\signtool.exe -d               
build\applets\signtool13winnt40\ -k"my key" -Z Import.jar classes\jars

where s: has been mapped\mounted to c:\release1.7 will produced a corrupt
jar file

this only really comes up as an issue because I'm try to write a makefile which 
runs from s: and signtool is at s:\build\applets... 

but if I try:

Comment 5

[Sonja Mirtitsch]

Hi Ian,
could you have a short look at signtool?

Comment 6

[Robert Relyea]

Ian, before you get too far on this, look at the output file Sonja produced. If
it has lots of <block of data><block of 'zero's> of the same size, I would say
it is problem the Win 2000/NSPR/Write to a network drive bug that we also saw in
pk12util. I'm adding Larry on the CC list for this.

Sonja, any application that we have that does more than one write will
potentially have this problem. The symptoms are:
1) tool works correctly on all platforms other than Win 2000.
2) tool works correctly on Win 2000 when ran with the NSPR Win95 libraries
(Win95 version of the tool).
3) tool fails when the output file is directed to a network drive on Win 2000.
4) tool works correctly on Win 2000 when the output file is directed a local
drive, even on Win 2000.
5) The failed output file is a mixture of 'N' blocks of data followed by 'N'
blocks of 0's.

bob

Comment 7

[Sonja Mirtitsch]

OK, I will check for these symptoms if I see a future failure on Win2K. What
about theroland's failures? Sounded like it was still a local drive, just
mounted on S: - is that treated as a network drive too?
Btw, my main problem is not that signtool fails, but that signtool, on failure
should not return 0.
Otherwise the QA scripts can't recognize the failure.

Comment 8

[Sonja Mirtitsch]

I think someone needs to look at the returncode, this causes completely
unreliable QA results, failures are reported as passes!

Comment 9

[Sonja Mirtitsch]

This needs to be fixed - QA results are unreliable if I canm't depend on the
returncode of the tools.

Comment 10

[Sonja Mirtitsch]

Wan-Teh, I think this bug should be fixed, because it makes the QA results
unreliable.
Please note that this is a bug on the returncode of signtool, and not on the
actual failure (which most likely has been fixed by Larry's NSPR fix), and may
or may not occur on Unix systems as well.
I don't assign this to Ian, since he does not have a Win2K machine.

Comment 11

[Wan-Teh Chang]

After I spoke with Jamie, a co-author of signtool, I think
this bug should be considered an enhancement request.  Second,
this bug affects all platforms, not just Windows 2000.

Jamie told me that although signtool does exit with a non-zero
status on some failures, that was not done consistently.
Signtool was originally implemented as an interactive tool,
so the exit status was not intended to be significant.

Now that we are using signtool in test scripts and checking its
exit status, the exit code of signtool should be significant.
This requires going through all the signtool source files though,
because the problem reported here is just one of the many places
that need to be fixed.

By the way, the error messages we saw
NOTE -- "nojs.jar" archive DID NOT PASS crypto verification.
  (reported reason: Corrupt JAR file)
came from the JarWho() function, which returns void. Duh.  If
you look at signtool.c, you'll see that the main() function
invokes the VerifyJar(), ListCerts(), JarListModules(), GenerateCert(),
and JarWho() functions without checking their return value.  This
would be a good starting point.

Comment 12

[Sonja Mirtitsch]

Then we need to change the messages to include something like "Failure", so my
scripts can search for this string.
It certainly doesn't make it easier for QA. In the meantime propose to add to
the release notes that signtool is untested, also we should be aware that this
decreases our coverage.

Comment 13

[Wan-Teh Chang]

Attachment: Proposed patch v1.

Comment 14

[Wan-Teh Chang]

The patch I just attached is my attempt at fixing this.
I started from the main() function and went through all
the code paths that may fail.  I believe I got most of
the failure cases to exit with -1, but there are a few
I didn't change because I don't understand whether
those failures are fatal. An example is an expired
certificate.

Jamie, could you please take a stab at this?  Review my
patch and use it as a starting point.

By the way, I have artificially made JarWho() fail and
verified that our test results.html showed two test
failures with signtool.  So my patch sort of meets the
minimum requirement -- signtool correctly exits with -1
when it encounters the error in the description of this bug.

Comment 15

[Jamie Nicolson]

This patch looks fine.

Comment 16

[Jamie Nicolson]

Fixed.

Checking in certgen.c;
/cvsroot/mozilla/security/nss/cmd/signtool/certgen.c,v  <--  certgen.c
new revision: 1.3; previous revision: 1.2

/cvsroot/mozilla/security/nss/cmd/signtool/list.c,v  <--  list.c
new revision: 1.3; previous revision: 1.2

/cvsroot/mozilla/security/nss/cmd/signtool/signtool.c,v  <--  signtool.c
new revision: 1.2; previous revision: 1.1

/cvsroot/mozilla/security/nss/cmd/signtool/signtool.h,v  <--  signtool.h
new revision: 1.2; previous revision: 1.1

/cvsroot/mozilla/security/nss/cmd/signtool/util.c,v  <--  util.c
new revision: 1.5; previous revision: 1.4

/cvsroot/mozilla/security/nss/cmd/signtool/verify.c,v  <--  verify.c
new revision: 1.2; previous revision: 1.1

Comment 17

[Wan-Teh Chang]

Attachment: Proposed patch #2, to be applied on top of the previous patch.

Comment 18

[Wan-Teh Chang]

I made a second pass through the signtool source code.
I just attached patch #2, which is to be applied on top
of the previous patch that Jamie checked in.

Jamie, could you review patch #2 please?  Thanks.

Comment 19

[Jamie Nicolson]

r=nicolson

Comment 20

[Wan-Teh Chang]

I checked in patch #2 on the trunk and NSS_3_3_BRANCH of NSS.

To summarize my changes:

signtool now exits with a nonzero status under the following
two conditions:
- signtool has an internal error; or
- the jar file is invalid (does not pass crypto verification).

Note that in the ListCerts() function, if the certificate is
expired but valid, signtool still exits with 0.

I also made sure that whenever signtool exits with a nonzero
status, an error message is printed, that is, there is no
silent failure.

Since signtool is an interactive tool, some of the signtool
tests may need to match its output with the expected output,
if the exit status alone does not convey enough information.