Closed
Bug 182318
Opened 22 years ago
Closed 21 years ago
Make the backward compatibility tests work with NSS 3.7
Categories
(NSS :: Test, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
3.9
People
(Reporter: wtc, Assigned: bishakhabanerjee)
Details
Attachments
(3 files)
975 bytes,
patch
|
Details | Diff | Splinter Review | |
1.40 KB,
patch
|
Details | Diff | Splinter Review | |
1.50 KB,
patch
|
Details | Diff | Splinter Review |
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 fips.sh 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 fips.sh, 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, fips.sh needs to expect
an exit status of 255 instead of 0 when no keys
are found.
Reporter | ||
Comment 1•22 years ago
|
||
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 fips.sh in NSS 3.2.2 work with the certutil
in NSS 3.7.
Reporter | ||
Updated•22 years ago
|
Priority: -- → P1
Target Milestone: --- → 3.9
Comment 2•22 years ago
|
||
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
else
certutil_k_returnvalue = 0
in 3.2.2 fips.sh:
if certutil_k_returnvalue != 0
compare this to the return value
else
compare 0 to returnvalue
=======
I also put additional information in the logs and in the result file:
tip:
result.html
List the FIPS module keys (certutil -K returned 255, should 255)
334:
result.html
List the FIPS module keys (certutil -K returned 0, should 0) Passed
output.log looks like the following now
fips.sh: 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
File
/share/builds/mccrel3/nss/nsstip/builds/20030213.1/booboo_Solaris8/mozilla/dist/SunOS5.8_DBG.OBJ/lib/libfreebl_hybrid_3.so:
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
File
/share/builds/mccrel3/nss/nsstip/builds/20030213.1/booboo_Solaris8/mozilla/security/nss/lib/softoken/SunOS5.8_DBG.OBJ/libsoftokn3.so:
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)
Comment 3•22 years ago
|
||
Comment 4•22 years ago
|
||
Assignee | ||
Comment 5•21 years ago
|
||
This has been working for a long long time, marking fixed.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•