fix tests of statically bound tools like signtool

NEW
Assigned to

Status

NSS
Test
P2
critical
9 years ago
9 years ago

People

(Reporter: Nelson Bolyard (seldom reads bugmail), Assigned: Slavomir Katuscak)

Tracking

3.11.1
3.11.10
Sun
Solaris

Firefox Tracking Flags

(Not tracked)

Details

(URL)

The NSS utility program signtool has been broken on Solaris for two years.
NSS initialization always fails when /usr/sfw/bin/signtool attempts it,
yet *our QA tests have utterly failed to detect this*.  See bug 464406 for 
details.

The flaw appears in tools that are linked with NSS's static libs (.a files).
Do we test them AT ALL?  
Do we test them in different directory configurations than the ones in 
which we install them?  

This must get fixed ASAP.
(Assignee)

Comment 1

9 years ago
I tried to copy signtool to different directory, set library path to build directory and call ./signtool -l -d dbdir, and this passed - so problem was not reproduced (tested on Apple machine, both 3.11 and 3.12 branches). Is there anything else I need to set to reproduce this failure ? 

Btw we already have one tests with different library path, see mangle test in fips.sh, but this is negative test expecting return value 46.

Do you want to have tests for all NSS tools, or signtool would be enough ?
At a minimum, we need to test every tool that we deliver that is built 
with NSS's static libraries.  There's a list of those in bug 464406.

This bug began in 3.11.1.  I don't know if it is present in 3.12.x or not.
To find out, you need to do a test that reproduces the problem with 3.11.x
and then repeat it with 3.12.x.
Slavo, go to any Solaris system on which the official patch that contains
NSS 3.11.x (x > 1) has been installed.  You need to ensure the following
things:
1. The directory $HOME/.netscape exists for the UID you're using, and is 
has permissions 07xx.  
2. LD_LIBRARY_PATH is empty, or does not contain any dirctory that includes
NSS shared libraries.
3. If $HOME/.netscape does not already contain NSS DB files, create them 
with /usr/sfw/bin/certutil -N

Then try listing the contents of the DB, first with certutil and then with
signtool.  e.g. 
/usr/sfw/bin/certutil -L
/usr/sfw/bin/signtool -L

You will likely notice that certutil succeeds (even if it outputs nothing),
but signtool fails. 

The task is to devise a QA test that can reproduce the problem without 
needing to change the contents of either /usr/sfw/bin or /usr/lib/mps.
(Assignee)

Comment 4

9 years ago
I see:
bash-3.00$ /usr/sfw/bin/signtool 
ld.so.1: signtool: fatal: libplc4.so: open failed: No such file or directory
Killed

After setting LD_LIBRARY_PATH it's all OK.

Our test suite sets both binary path and library path in common/init.sh (which is sourced before testing):

PATH=.:${DIST}/${OBJDIR}/bin:${DIST}/${OBJDIR}/lib:/bin:/usr/bin:$PATH
LD_LIBRARY_PATH=${DIST}/${OBJDIR}/lib:$LD_LIBRARY_PATH
(similar settings also for other OS)

I don't really understand what should we test there. Should we just skip setting library path ? If this is the case, then I see this more as OS configuration problem than NSS bug.
(Assignee)

Comment 5

9 years ago
Nelson, please clarify what we should test there. This bug has not priority set, I'm assigning it to P2 for now, if this is ASAP work, please reassign to P1.
Priority: -- → P2
Slavo, For NSS products installed in Solaris (or installed in their official
places on other OSes), it should not be necessary to use LD_LIBRARY_PATH.
But apparently, with some programs, it is presently necessary, due to this
bug.  

Our QA tests need to be able to test this.  They need to 
a) demonstrate that this is presently broken, and 
b) demonstrate that it is fixed, if and when it gets fixed.
You need to log in before you can comment on or make changes to this bug.