Closed Bug 182318 Opened 22 years ago Closed 21 years ago

Make the backward compatibility tests work with NSS 3.7


(NSS :: Test, defect, P1)



(Not tracked)



(Reporter: wtc, Assigned: bishakhabanerjee)



(3 files)

NSS 3.7 introduces the new cert8.db and will upgrades
cert7.db to cert8.db whenever possible.

This breaks the backward compatibility tests because
some of the tools (certutil, modutil, and signtool)
are statically linked with the old NSS (3.2.2) and
continue to use cert7.db while others (pk12util,
selfserv, tstclnt, and strsclnt) are dynamically
linked with the new NSS (3.7) and use cert8.db.

These test failures do not indicate backward
compatibility problems of the NSS shared libraries
but rather indicate interoperability issues between
NSS 3.7 and older NSS releases.

One way to make the backward compatibility tests
work with NSS 3.7 is to have all the tools use
the new NSS.  This means the statically-linked
tools (certutil, modutil, and signtool) must come
from the new NSS.  (Actually starting in NSS 3.4
certutil is dynamically linked, but modutil and
signtool are still statically linked.)

One more change to the script is required.
In NSS 3.4, the exit status of certutil changed
from 0 (success) to 255 (failure) when no keys
are found.  (This change is to fix bug 115660.
See certutil.c, rev. 1.43 and, rev. 1.6.)
Strictly speaking, this change of certutil's exit
status breaks backward compatibility, but it is
too late to change it back now.  So, if we are
using NSS 3.7's certutil, needs to expect
an exit status of 255 instead of 0 when no keys
are found.
There may be a better way to handle the different exit
status of certutil in NSS 3.4 or newer, but this patch
makes the in NSS 3.2.2 work with the certutil
in NSS 3.7.
Priority: -- → P1
Target Milestone: --- → 3.9
I solved the problem in a different way. I set a variable in the wrapper:

if the NSS version is 3.[789].x, or tip
  set PATH to use 3.7.1 statically linked tools
  certutil_k_returnvalue = 255
  certutil_k_returnvalue = 0

in 3.2.2

if certutil_k_returnvalue != 0
  compare this to the return value
  compare 0 to returnvalue


I also put additional information in the logs and in the result file:
    List the FIPS module keys (certutil -K returned 255, should 255)
    List the FIPS module keys (certutil -K returned 0, should 0) Passed

output.log looks like the following now List the FIPS module keys.
* this script was modified to handle the certutil return change
* return is supposed to be 255 for this test
certutil -d ../fips -K -f ../tests.fipspw.115
1419268 bytes
  hash: 20 bytes
    87 b9 db 0f 59 80 4c 64 37 45
    41 73 20 80 21 7d 3a d2 ad 5e
  signature: 40 bytes
    29 be 76 e2 47 c5 cb ec bc 5b
    71 2a 6c e2 10 37 e3 45 b8 87
    2a 4c 7a ce 79 57 e6 73 88 1f
    34 24 16 ef 59 a7 8d a5 74 1e
Verified : TRUE
3748616 bytes
  hash: 20 bytes
    6d 62 7a d4 9b 8a 52 8e 1f be
    cb 83 b9 ff e1 cb ab 50 e9 9c
  signature: 40 bytes
    11 04 2b 34 d3 1a d3 59 0c 6a
    23 fa 5a 55 38 c1 25 82 70 2c
    69 59 32 93 3e 62 29 45 a3 eb
    fa 2d ab fb 5a 42 fb 15 e5 1d
Verified : TRUE
certutil: no keys found

I am not certain that your (or my) wrapper is still similar to what is checked
in, I'll attach a patch that is against my internal wrapper version if you want,
or check my entire changes into mozilla (which might break the tinderboxes)
This has been working for a long long time, marking fixed.
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.