237982 - plain migration of Mozilla profile makes SSL component unusable

Status: RESOLVED DUPLICATE of bug 176501

(Core :: Security: PSM, defect)

Description

[Jan Kozanek]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

First, it might be just an issue when upgrading from M 1.1 to M 1.6, couldn't
test it with others.

After full removal and fresh install of 1.6 Mozilla correctly found and opened
my user profile in my homedir. However all SSL related functions were disabled
with this error: "Could not initialize browser's security component..." I used
the tarball auto-installer.

Suggested permissions or disk space problems were not the cause.


Reproducible: Always
Steps to Reproduce:
1. Full removal of old version, keeping your user profile intact
2. Fresh install of M 1.6
3. Start it, choose your old profile and voila - no SSL functions

Actual Results:  
In Prefs --> Security --> Master pwd --> Change pwd there was no Security device
to select, no chance of entering or changing your master password and gaining
access to your stored security credentials. As well as disabled access to all
ciphered websites and mailboxes.

Expected Results:  
Either perform my simple solution below automagically or offer a proper profile
migration or at least warn that such an issue might arise.

After few hours of silly test & try I found a solution - of course I didn't want
to lose all my user settings and even saved security data:

1. deleting "secmod.db" and "secmodule.db" in your old profile dir
2. copy "secmod.db" from a fresh profile created by M 1.6 to your old profile dir

Comment 1

[David L Durant]

Duplicate symptoms, platform WinXP, Mozilla 1.7 RC1.
Upgraded from Moz 1.6 to 1.7b, no problem.
Upgraded from Moz 1.7b to 1.7rc1, disabled security module.

Analysis: the secmod.db file referenced:
C:\Program Files\Common Files\mozilla.org\GRE\1.7b_2004031616\nssckbi.dll
whereas a freshly created Profile secmod.db referenced:
C:\Program Files\Common Files\mozilla.org\GRE\1.7b_2004042109\nssckbi.dll

Solution: copied the latter over the former secmod.db.
The upgrade removed the older .dll, but the migration did not update secmod.db.

Note that my PC has SmartCard options in the BIOS,
and that my default security module was NOT "Software Security Device".

Comment 2

[Jan Kozanek]

(In reply to comment #0)

Just one more detail to the orig. descr.:

I was using before as well as after the unsuccessful migration the internal
Software Security Device.

So then, according to David's experience, this bug is obviously not specific to
the type of security device one is using.

Comment 3

[Kai Engert (:KaiE:)]

From the way you describe the behaviour, the problem is with NSS, I think.

Looks like modern versions of NSS do not behave correctly when having to deal
with some old versions of security databases.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

NSS must be CONFIGURED by the application (on behalf of the user) to know 
which PKCS#11 "modules" to use.  NSS provides the API by which this configuration is performed, but the appliation must do it.  

That configuration is stored in file secmod.db in a directory whose name is 
supplied by the aplication.  NSS itself is not reponsible for being self-configuring.  

If the appliation configures NSS to use a certain shared library in a 
certain directory, and then the application (through an "upgrade" or 
"migration" chooses to MOVE that shared library to another directory, it is 
the responsibility of that application to reconfigure NSS (NSS's secmod.db) 
to use the new directory.  

So, this bug in an application migration issue, not an NSS bug.

Application hints:

Note that one option is to configure NSS to use a shared library by its
simple file name, not the full path name.  Then if the shared lib can 
be found in the PATH (on Windows) or the LD_LIBRARY_PATH (or equivalent)
on Unix, it will load without the full path name being configured.  
And if the file is moved, but remains in the path (or the path is changed
to include the new directory) then the secmod.db need not be changed for
migration.  

Also, IINM, on windows, the directory where the executable lives is 
always implicitly at the head of the library path, so if the secmod.db
contains the simple file name (not a path name) and the file is with the
executable, it should just work, IIRC.  

I'm giving this bug back to PSM, the component of mozilla browsers that 
interfaces with NSS.  Perhaps it should be given to another component 
(e.g. "migration" if that is one).

Comment 5

[timeless]

this might be a duplicate of the bug(s) about locked nssckbi.dll

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

I think this is a dup of bug 176501, or vice versa.

Comment 7

[timeless]

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