User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082618 Minefield/3.0a8pre See <https://bugzilla.mozilla.org/show_bug.cgi?id=390451#c47> and previous. My setup is as follow: FF2 installed to c:\Programme\Mozilla.org\Firefox using Profile kstrebel_fx2 FF3 installed to c:\Programme\Mozillo.org\Firefox3 using Profile kstrebel_fx3 after updating FF3 to Alpha7, no stored password are displayed, even after setting the master-password again. I renamed the kstrebel_fx3 directory and copied kstrebel_fx2 over to kstrebel_fx3, restarted FF3, set master-password again -> no stored passwords are shown. Reproducible: Always Steps to Reproduce: 1. Copy FF2 profile to FF3 profile 2. Start FF3 3. Reset master password 4. Check stored password list Actual Results: No passwords shown Expected Results: List of 186 stored passwords shown

Try as I have, I cannot reproduce this bug. Since your profile seems to be quite extensive, could you please provide a copy of both profiles that you are testing with. Just zip them and attach them to this bug. Thanks.

I'd specifically be interested in seeing what the values of the signon.SignonFileName and the signon.SignonFileName2 prefs are, if those files exist, and if signons.txt and/or signons2.txt are present.

Oh, and... > i found my fx2 signon.SignonFileName pointing to 99556210.s Take caution in attaching any .s files to bugzilla; the passwords stored in that old file format are not encrypted -- they are simply obscured.

Hm, i'll make a 'test' profile with only some accounts i don't care to much ;-) ...

... hm, just zipping and attaching is not really easy. The zip profiles are about 12 MB each and only 300 KB are allowed for non-patch uploads. At first, i try to upload packed key3.db and signon*.txt's ... Justin, signon.SignonFileName and signon.SignonFileName2 are set to default. I removed the 99556210.s ( didn't seem to bother FF3 ), so i have no signons.txt ( neither for FF2 - which is working, nor for FF3 ). I made a diff on the signons2.txt and key3.db file in the FF2 and FF3 profile, only the key3.db's differ, is that ok?

I should mention the key i used, try 'TestPwd01' ;-).

I can reproduce what you are seeing I believe with the files you provided. Here are the steps I followed: 1. Start with a completely clean WinXP 2. Download and install Firefox 2.0.0.6 using the defaults 3. Start Firefox to allow it to set up the default profile 4. Copy the key3.db and signons2.txt files to the default profile 5. Restart Firefox and check saved passwords/master password - they exist 6. Download and install Minefield 20070828 accepting defaults 7. Start Minefield - At this stage, Minefield converts the default profile to be used with Firefox 3. 8. Check saved passwords/master password in Minefield - master password has been disabled, no saved passwords exist 9. Close Minefield, start Firefox 2.0.0.6. 10. Check saved passwords/master password in Minefield - master password has been disabled, no saved passwords exist So in short, upgrading your profile from FF2 to FF3 appears to wipe your password settings. I will see if I can reproduce this on a clean profile.

I am not able to reproduce this starting with a clean profile and loading it with 10 saved passwords (some http, some https, and a ldap), following the same steps I listed above. Klaus, could you please try using a new profile and loading it with a small set of passwords and a master password to see if you can reproduce the results I am seeing? Thank you.

(In reply to comment #7) > I can reproduce what you are seeing I believe with the files you provided. Hmm. If you enable |signon.debug|, pwmgr will log some data to the terminal and the Error Console (you'll need to enable |javascript.options.showInConsole| for the latter to show up). Do you see any error messages in either place when starting FF3 with the old profile and checking to see passwords exist?

(In reply to comment #7) > I can reproduce what you are seeing I believe with the files you provided. > Here are the steps I followed: > > 1. Start with a completely clean WinXP > 2. Download and install Firefox 2.0.0.6 using the defaults > 3. Start Firefox to allow it to set up the default profile > 4. Copy the key3.db and signons2.txt files to the default profile > 5. Restart Firefox and check saved passwords/master password - they exist > 6. Download and install Minefield 20070828 accepting defaults > 7. Start Minefield - At this stage, Minefield converts the default profile to > be used with Firefox 3. > 8. Check saved passwords/master password in Minefield - master password has > been disabled, no saved passwords exist Set the same master password as used in Firefox 2.0.0.6 and see what happens. I don't care about your steps 9. and 10. and i think it's ok that after converting the profile for Minefield, Firefox will not be happy with it. Just to clearify my config in profiles.ini: [General] StartWithLastProfile=0 [Profile0] Name=kstrebel_fx2 IsRelative=0 Path=D:\Users\kstrebel\mozilla\kstrebel_fx2 [Profile1] Name=kstrebel_fx3 IsRelative=0 Path=D:\Users\kstrebel\mozilla\kstrebel_fx3 Default=1 Is start FF2 with: "C:\Programme\mozilla.org\Firefox\firefox.exe -Profile D:\Users\kstrebel\mozilla\kstrebel_fx2" and Minefield with: "C:\Programme\mozilla.org\Firefox3\firefox.exe -Profile D:\Users\kstrebel\mozilla\kstrebel_fx3" > 9. Close Minefield, start Firefox 2.0.0.6. > 10. Check saved passwords/master password in Minefield - master password has > been disabled, no saved passwords exist > > So in short, upgrading your profile from FF2 to FF3 appears to wipe your > password settings. I will see if I can reproduce this on a clean profile. > Problem is, even after setting the same master password, stored passwords in signons2.txt are not shown/used.

(In reply to comment #8) > I am not able to reproduce this starting with a clean profile and loading it > with 10 saved passwords (some http, some https, and a ldap), following the same > steps I listed above. > > Klaus, could you please try using a new profile and loading it with a small set > of passwords and a master password to see if you can reproduce the results I am > seeing? > > Thank you. > Removed all from my profile dir, started Minefield, new profile is created, master password set, store a password, password is stored, stopped, copied just signons2.txt, started, no password is shown. Is the format of signons2.txt changed?

(In reply to comment #9) > (In reply to comment #7) > > I can reproduce what you are seeing I believe with the files you provided. > > Hmm. > > If you enable |signon.debug|, pwmgr will log some data to the terminal and the > Error Console (you'll need to enable |javascript.options.showInConsole| for the > latter to show up). > > Do you see any error messages in either place when starting FF3 with the old > profile and checking to see passwords exist? > Ahh, yes! PwMgr Storage: Failed to decrypt string: MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECG2sajtzuQyXBBiC5Lws4v5mpCDFn5xS/v0dOEa75czEPqU= (NS_ERROR_FAILURE) PwMgr Storage: Failed to decrypt string: MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECJTfFgwAn5H0BAigIKfzXA5hSQ== (NS_ERROR_FAILURE) masterpassword is definitly matching!

And annother one, i've set 'signon.signonFileName2 to the complete (DOS) path of my signons2.txt file ... and it only stored null passwords ?!?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007092005 Minefield/3.0a8pre signons2.txt: #2d . https://usercenter.checkpoint.com username MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECCp0Wh3eIrsLBBhkhqcG7FqodGSAMeYD3IgmSPIgnkh6Sp0= *password MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECI3WAWm4KnUqBBCkWgu0S5cszfj/w7k80/r5 https://usercenter.checkpoint.com . https://support.sgi.com USER_ID MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECHhAM2/zyQUwBAhTdMTH0FDBSA== *PASSWORD MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECKO1MGLfPwa8BAjYs89L6cxoOA== https://support.sgi.com . http://www.bechtle.de F245_name MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECLvYjyORnWF+BBDcNNRBVP42x92Rb3wd6g9y *F246_name MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECGnUaHj/X/jtBBCoHvkG/UavH6eZ4RIeJUr1 http://www.bechtle.de . MasterPassword: TestPwd01 Log: Login Manager: Getting a list of all logins PwMgr Storage: Failed to decrypt string: MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECCp0Wh3eIrsLBBhkhqcG7FqodGSAMeYD3IgmSPIgnkh6Sp0= (NS_ERROR_FAILURE) PwMgr Storage: Failed to decrypt string: MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECI3WAWm4KnUqBBCkWgu0S5cszfj/w7k80/r5 (NS_ERROR_FAILURE) PwMgr Storage: Failed to decrypt string: MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECHhAM2/zyQUwBAhTdMTH0FDBSA== (NS_ERROR_FAILURE) PwMgr Storage: Failed to decrypt string: MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECKO1MGLfPwa8BAjYs89L6cxoOA== (NS_ERROR_FAILURE) PwMgr Storage: Failed to decrypt string: MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECLvYjyORnWF+BBDcNNRBVP42x92Rb3wd6g9y (NS_ERROR_FAILURE) PwMgr Storage: Failed to decrypt string: MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECGnUaHj/X/jtBBCoHvkG/UavH6eZ4RIeJUr1 (NS_ERROR_FAILURE) And ... log when additionally tried to save the bugzilla password: Login Manager: Searching for logins matching host: https://bugzilla.mozilla.org, formSubmitURL: https://bugzilla.mozilla.org, httpRealm: null Login Manager: Adding login: [xpconnect wrapped nsILoginInfo] PwMgr Storage: Writing passwords to D:\Users\kstrebel\mozilla\kstrebel_fx3\signons2.txt Looks like minefield doesn't like the migrated signons2.txt at all :-(

... even better: deleted the signons2.txt and started minefield, logged it to bugzilla, tried to save password ( Master is still TestPwd01 ): Login Manager: Adding login: [xpconnect wrapped nsILoginInfo] PwMgr Storage: Writing passwords to D:\Users\kstrebel\mozilla\kstrebel_fx3\signons2.txt PwMgr Storage: Failed to encrypt string. (NS_ERROR_FAILURE)Error: 'Couldn't write to file, login not added.' when calling method: [nsILoginManagerStorage::addLogin] = NS_ERROR_XPC_JS_THREW_STRING Source file: file:///C:/Programme/mozilla.org/Firefox3/components/nsLoginManager.js Line: 363 signons2.txt is: #2d . ok, i'll delete key3.db and signons2.txt and try again ... PwMgr Storage: User canceled Master Password, aborting write.

Ok, i removed key3.db and signons2.txt, set the MasterPassword 'TestPwd01', logged in to the sites in the old files and stored the passwords: worked perfekt . See dir output ( .sik are the files from FF2 ): 21.09.2007 10:05 16.384 key3.db 21.09.2007 09:43 12.288 key3.db.sik 21.09.2007 10:04 737 signons2.txt 29.08.2007 09:10 735 signons2.txt.sik so both files are different in size, the signons2.txt keys are different even with same MasterPassword: NEW: https://support.sgi.com USER_ID MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECHLISrj+vvnmBAhsuW3VPMBIxA== *PASSWORD MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECMG4/30iRm1YBAikxVlLbIqphg== https://support.sgi.com . ^ ^ | | v v OLD: https://support.sgi.com USER_ID MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECHhAM2/zyQUwBAhTdMTH0FDBSA== *PASSWORD MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECKO1MGLfPwa8BAjYs89L6cxoOA== https://support.sgi.com . ( bechtle changed the Login-Form, you can forget this one ) if we only could import these stuff, but the Password-Import/Export-Extension doesn't work with FF3 since Alpha 7 :-(.

So... 1. When key3.db is recreated, the encryption key it contains is different. Even if you use the same master password. 2. Entries are stored with a salt, so storing the same password with the same key3.db will result in a different value Let me try to reproduce what ahughes did in comment #7... That's the only solid data I see to work with.

I can also reproduce as in comment #7. I enabled pwmgr logging before restarting, and saw this when the storage module initialized on startup: Login Manager: Counting logins matching host: http://www.mozilla.org, formSubmitURL: , httpRealm: null PwMgr Storage: Initializing key3.db with default blank password. PwMgr Storage: Reading passwords from /Users/dolske/Library/Application Support/Firefox/Profiles/mwze73td.newprofile/signons2.txt Viewing a list of stored logins gave me lots of errors like: Login Manager: Getting a list of all logins PwMgr Storage: Failed to decrypt string: MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECIgPVvbFnI7EBBAsJGjkp7VI5ZlOwktumFta (NS_ERROR_FAILURE) PwMgr Storage: Failed to decrypt string: MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECL11os4yPZeQBBDHFJxQ5tpvZGeoe8mnAkgL (NS_ERROR_FAILURE) PwMgr Storage: Failed to decrypt string: MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECGQdRfduWY59BAiMbhV6vx2Ymg== (NS_ERROR_FAILURE) The "Use Master Password" checkbox wasn't enabled; enabling it and setting the password to the old value didn't allow successfully decryption either. This looks like a NSS bug; something seems to not like the pre-FF3 key3.db. I'll investigate a bit more, and probably file a new NSS bug with a concise summary and dupe this to it.

Justin filed bug 397122 about this. I looked at it. This key3.db file is missing a major piece, a record in the DB known as the "global DB salt". This probably explains why the file is only 12 KB in size, and all other key3.db files are 16KB. This is the first key3.db file that I ever recall seeing that was only 12KB. Apparently, older versions of NSS were happy to live without the global salt, but the NSS in FF3 treats the DB as uninitialized if it does not exist. It's easy enough to make NSS 3.12 alpha (the version for FF3) work like the previous version, but I'm not at all certain that a key DB without a salt is really giving secure behavior. Maybe we should generate a missing salt. My questions for you all are: How did you generate this key3.db? With what version of NSS (or FF) was it created? Have you had it for a long time? (how long, how many years?) Has it been through many version upgrades of FF? Are you able to create 12KB key3.db files at will? If so, how?

1. Hm, let's say 'programmaticaly'. Initially created and then migrated many times till FF3 was reached :-). 2. Very very hard question, i'm not sure, if Netscape 4 already had it, i think it had the first version of the PasswordManager. 3. I guess 10 years or so ( wow ! ). 4. Netscape 4 to Mozilla 0.x to Mozilla 1.x to Firefox 0.x to Firefox 1.x to Firefox 2.x to Firefox 3.x :-) 5. Hm, all FF2 profiles i create have to 12k ( and smaller ) key3.db without salt. My day-2-day FF is 'Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7' at the moment ... have to check this with a clean new profile ...

Ok, checked it out. Usually, when i create a new profile, i setup the profile using ProfileManager, copy my standard ( old ) profile over before i start FF ( wanna keep my bookmarks and stored stuff ) and start FF, that's where the < 16K key3.db's come from. When i create a vanilla profile, the key3.db is 16K. So, i think we'd need a way to upgrade the key3.db lacking a salt and 'recrypt' the signons.txt files. Or, other way round, a tool to import the files created by the 'Password Exporter'-AddOn ( perhaps that Extension will be ported soon, the author seems to be waiting, 'till the NSS API is stable. ), with a big big warning of passwords propably getting lost before installing. My signons2.txt grew to 180 entries during the last 10 years :-).

The NSS API for password encryption has been stable for at least 3 years now, probably more like 7. The NSS QA test programs include a program for decrypting signons.txt (assuming you have the key3.db and the master password). It dates back to march 2004. When bug 397296 is fixed, this bug may just disappear. If so, then this bug can be marked as a duplicate of that one.

Hi all, just tested with my prehistoric key3.db+signons2.txt files on 'Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101504 Minefield/3.0a9pre' and ... prefect, all passwords are there. Just an idea for the NSS-API guys: perhaps, if missing global-salt is detected, there should be an 'upgrade' process, generating a new key3.db and reencrypting the signons2.txt with the new key ( well, both to temp-files first, renaming the old ones and using the new ones on successful processing ) to get an 'uptodate' key3.db.