200215 - after ugrade 1.3 -> 1.4a nightly, "Could not initialize the browser's security component"

Status: RESOLVED DUPLICATE of bug 200775

(NSS :: Libraries, defect, P2)

Description

[Vaclav Dvorak]

After upgrading from 1.4a_2003031216 (?? - version extracted from secmod.db, I
though it was 1.3) to recent 1.4a nightlies (tried several, e.g. 2003033108), I
was getting a "Could not initialize the browser's security component" the first
time I hit a https site or tried using Single Signon. Deleting the secmod.db
file solved the problem. I have no idea what was lost by doing that - but
everything seems to work now.

I still have the problematic secmod.db, so I can attach it if you convince me it
contains nothing private. :-)

Comment 1

[Matthias Versen [:Matti]]

-> PSM (Security:general!=crypto)

Comment 2

[Kai Engert [:KaiE:]]

Over to NSS.
Either NSS corrupted the file itself, or possibly some other file I/O failure
occurred?

Comment 3

[Jack Nerad]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

After I upgraded from 1.3 -> 1.4a, I saw the same behavior.  Suggested fix by
Vaclav, deleting secmod.db worked, but I don't know what I lost.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Please attach the secmod.db file here.  It only contains the pathnames of the
shared libraries that NSS loads to do crypto.  It's the DB that lists the
configurable security modules.  If NSS cannot load the shared libraries it 
needs, it will fail.  When you delete it, NSS will recreate a default one
again, which will be OK unless you have any third-party crypto modules, 
such as libraries for hardware crypto devices.

It might be instructive to attach both one that fails and one that works.

Marking P2 because this seems to be a confirmed regression, at least from the
user's perspective.  

Comment 5

[Vaclav Dvorak]

Attachment: the secmod.db file in question

So here it is - at least I hope it's the right one...

Comment 6

[Wan-Teh Chang]

Nelson, could you take a look at this?  Thanks.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

submittor, please attach both secmod.db files.  You attached one.
Now please attach the other.   Thanks.  

Comment 8

[Vaclav Dvorak]

Attachment: my current secmod.db that works with build 2003033108

OK, here's my current secmod.db file that works. The build that I currently use
is 2003033108. Yeah, I know, I should upgrade...

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Until modutil is fixed, there's not much I can do with these secmod.db files.
Sigh.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

My comment 9 above was incorrect.  Please ignore it.

Here is a summary of the problem in this report, and my analysis of it.

Several mozilla users reported that they were unable to use mozilla's crypto
features after upgrading from 1.3 to 1.4a or a 1.4 nightly.  Deleting their
secmod.db file cured the problem.  The submittor of this bug attached two 
secmod.db files, one that worked and one that did not.  

I dowloaded the two secmod.db files into different directories, and printed
their contents using the NSS command:

    modutil -rawlist -dbdir <dir-name> -nocertdb

and observed two differences:

1. Different internal modules.  One was using FIPS, the other was not.
The one using FIPS was reported as not working.

2. Different absolute pathnames for nssckbi.dll.  The user had several copies
of mozilla installed, but all of them were using the same copy of nssckbi.dll.

I do not know why installing 1.4a would have changed the user's secmod.db 
file to use the FIPS module, but I do know that the FIPS module was not 
working in several of the 1.4 nightlies.  That problem was fixed long ago.
I will mark this bug as a duplicate of the bug about FIPS broken in 1.4a.

*** This bug has been marked as a duplicate of 200775 ***