Open Bug 119371 Opened 18 years ago Updated 13 years ago

root cert library should use absolute path when automatically added

Categories

(NSS :: Libraries, defect, P2, major)

3.3.1

Tracking

(Not tracked)

REOPENED

People

(Reporter: jamie-bugzilla, Assigned: rrelyea)

References

Details

The root cert library is automatically added to secmod.db when NSS is started
up, if the library is in the database directory. However, if the database
directory is passed in as a relative path to NSS_Initialize, then the root cert
library path will be stored as a relative path. Then if the application is ever
run from a different directory, the library's path will no longer be valid and
the root certs won't be found. The path should be stored as an absolute path.
Target Milestone: --- → 3.4
Assigned the bug to Bob.
Assignee: wtc → relyea
Priority P2.  The fix doesn't seem hard, but Jamie has a workaround.
Priority: -- → P2
I'm also not sure we want to fix this.
1) Is there NSPR functions that work cross platform to accomplish this?
2) Are we in danger of breaking applications that depend on this behavior (there
has been some talk about purposefully doing this in PSM so that different
versions of Mozilla will get different version of the built-ins.
Bob,

No, there is no NSPR function that converts a relative pathname
to an absolute pathname.

It seems wrong for an application to purposefully depend on
this "bug".
But I don't consider it a bug.

Relative paths are a feature in secmod.db. Applications which are sensitive
should use full paths on their own.
OK, but the problem here is the path to the .so is not passed in directly by the
user, it is constructed from the database path. The user doesn't expect that
their database path is going to get converted into a filename that is
permanently stored somewhere. If they add a new module manually, they might
expect that relative paths will be stored as relative paths. But the root cert
module addition happens behind the scenes. The bottom line is, there is no
connection in the user's mind between what they do (use a relative path to
specify the database directory) and what NSS does as a result (sets up the
databases so that in the future they will only work properly from one place).

Case in point: I, a very experienced and knowledgeable user of NSS, was
unpleasantly surprised and confused by this behavior. How do you think other,
less experienced users will react?

*** This bug has been marked as a duplicate of 116315 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Priority: P2 → P1
Resolution: --- → DUPLICATE
This is in fact a different bug. Reopening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Priority: P1 → P2
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
This is a reasonable sematic change request, but semantic changes have binary
compatibility issues, so set target to 4.0
Target Milestone: 3.4 → 4.0
is this the issue that the secmod.db file contains the configdir= absolute path ?

This is a show stopper for people who like moving profiles around...
Blocks: 196119
QA Contact: bishakhabanerjee → jason.m.reid
QA Contact: jason.m.reid → libraries
You need to log in before you can comment on or make changes to this bug.