464408 - fix tests of statically bound tools like signtool

Status: RESOLVED INVALID

(NSS :: Test, defect, P2)

Description

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 1

[Slavomir Katuscak]

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 ?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 4

[Slavomir Katuscak]

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.

Comment 5

[Slavomir Katuscak]

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.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 7

[Marcus Burghardt]

Hi,

This is a very old bug without activity.
Marking as INVALID (for current days).

Thanks,