Closed Bug 192917 Opened 22 years ago Closed 22 years ago

Unable to change/set/reset master passwords

Categories

(Core Graveyard :: Security: UI, defect, P3)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: tom.hoffman, Assigned: ssaux)

References

Details

(Whiteboard: fixed1.3)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 I recently upgraded from 1.3a to 1.3b. I daily have to access development and production level websites that require web certificates. I've had no problem until this point. When I first used 1.3b, upon accessing one of these sites, I was prompted for a password for the "Software Security Device" which I've never used before, and obviously didn't know the password. So I reset the master password, and expected behavior is to get a prompt to set this new password the next time I'd access a site that required it. I never got that prompt, and was denied access to the sites. So I figured my profile was just hosed. When using a new profile, I was in fact prompted to set the new master password. Except this time, when setting the password, pressing "OK" does nothing. Reproducible: Always Steps to Reproduce: 1. Attempt to access any secure site that requires certificates. 2. See Master Password prompt 3. Do you know your password? Part 2 1. Reset master password 2. Attempt to access secure site that requires certificates 3. See prompt to set new master password 4. Enter new password, press OK Actual Results: Part 1 - I don't know what my password is, can't enter it, therefore I can't access the website. Part 2 - Press OK does nothing, can't continue. Expected Results: Part 1 - I don't know what I'm all of a sudden being prompted for this password in the first place Part 2 - Pressing OK should have set the new password.
*** Bug 192918 has been marked as a duplicate of this bug. ***
confirming based on dup....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.3?
I saw what is essentially this problem with an older profile where the Master Password was never set and with a new profile. Alternative steps to reproduce: 1. Create a new profile and switch to it. 2. Select Edit -> Preferences -> Privacy and Security -> Master Password and then click on the "Change Password" button. 3a. If "Generic Crypto Services" is selected, attempts to set the password result in an "Unable to change master password" error dialog. Perhaps this is "by design" but it is also confusing. 3b. If "Software Security Device" is selected, clicking the OK button has no effect. Cancel and Help both work fine.
When I try to set the master password for "Software Security Device" the OK button does nothing. The JavaScript console says: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIPK11Token.initPassword]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://pippki/content/password.js :: setPassword :: line 208" data: no]
high-visibility regression. We need to get this fixed for 1.3. Who can own this problem?
Flags: blocking1.3? → blocking1.3+
*** Bug 193067 has been marked as a duplicate of this bug. ***
I'm confused. In your comment say, you clicked "change password" in the master password pane, but the window contents that you are describing are not part of that dialog - what you describe is part of the "manage security devices" dialog.
-> PSM
Assignee: dveditz → ssaux
Component: Password Manager → Client Library
Product: Browser → PSM
QA Contact: tpreston → junruh
Version: Trunk → unspecified
I can not reproduce the problem. I can change the password. I can reset the password. I do not see the exception in the JS console. The problem report somehow sounds as if your installation is broken. I wonder if PSM is not correctly installed on your system. Did you install to a clean directory? Could you quit Mozilla, try to delete the file compreg.dat in your Mozilla installation directory (components subdirectory) and restart Mozilla, and see whether you still have the problem?
I still get the same behavior when following the steps in comment #9. I'm still prompted for a master password for a security device, and can't reset the password, and in the MozillaControl profile, I still get the prompt to set the master password, but pressing "OK" does nothing.
Confirming when installing 1.3b over 1.3a. Installing 1.3b into a clean directory works fine when setting or changing the master password.
Priority: -- → P3
Version: unspecified → 2.4
It appears that if I remove .\components\nppl3260.xpt and .\components\psm.xpt (which are not found in 1.3b) from the bad install, (1.3b installed in same folder as 1.3a) password manager works again.
Blocks: 192984
adding dependency on bug 193197
Depends on: 193197
Mine was an upgrade install (1.3b over 1.3a). I removed .\components\psm.xpt and .\components\compreg.dat, restarted Mozilla, and this bug has disappeared.
I do not have "nppl3260.xpt" or "psm.xpt" to delete. Could this be because I uninstalled 1.3b and reinstalled to try to get around this problem?
Depends on: 193241
For what it's worth, I also installed on top 1.3b on top of an older version (I dont recall which) and started getting these spurious prompts for password for the software security device. In my case, I didnt have much to lose so I did a "Reset Password" in the master password security pref dialog. I have not had another prompt since.
Actually, this did work for me too...but, I had to "Disable FIPS" in the Security Device Manager in order for this to work.
*** Bug 193490 has been marked as a duplicate of this bug. ***
Kai, drivers want this fixed for 1.3, but time is running out. What can be done? I'm cc'ing ssu in case there's an easy installer fix. /be
> Kai, drivers want this fixed for 1.3, but time is running out. What can be > done? I'm cc'ing ssu in case there's an easy installer fix. Sorry, I had not yet looked into the issue, I thought we had already agreed it's a packaging problem and I didn't look further. So I just had a deeper look. Not to say I understand what's going on, but here is what I see: Go to ftp.mozilla.org, and look at the psm.xpi for 1.3 alpha on windows. It contains the 3 PSM DLL files, which are pippki.dll, pipnss.dll, pipboot.dll, and it contains one xpt file, named psm.xpt. This confuses me, I have not worked on xpt file creation before, and I always assumed we create one xpt for each dll. Anyway, I tried to find psm.xpi for the windows 1.3 beta release. I didn't find one. So I did a web installer based windows install of 1.3 beta. When that was finished my installation directory contained again all 3 dll files, but now it no longer contains psm.xpt, but a pippki.xpt. I don't understand why the file is named differently in alpha and beta. If there was a bug in alpha which named the file incorrectly, I propose we enhance the 1.3 final installer, to make it delete the previously psm.xpt file.
blame the gre people. although psm has to be optional for export reasons it's now part of core... i'd suggest we undo that :-)
kai, if you install 1.3a and upgrade to 1.3b, you should see psm.xpi left in the components dir. I haven't tried to see if having this psm.xpi causes this bug. junruh filed bug 193241 indicating that the left over psm.xpi (and real player's nppl3260.xpt) is the cause of this bug. I'm not so sure about nppl3260.xpt since it's not ours. However, psm.xpi being left around is definitely a bug. I'll test going from 1.3a -> 1.3b and see if psm.xpi is the cause of this.
Just to clear up some confusion, we should be careful whether we write psm.xpI or psm.xpT. The left over file is psm.xpT, which is the one that should get deleted. When I spoke about psm.xpI in my comment 20, I was refering to the Install Package that is separately available on the ftp server and used during installation. So psm.xpI is part of the installation package in 1.3a, psm.xpI contains psm.xpT. In 1.3b, there is no longer a separate package for psm available, therefore no longer a psm.xpI package. And the core gre/browser package, that now contains the psm files, no longer contains a psm.xpT file either, as we have found out. No new information in this comment, just trying to prevent potential confusion between xpi and xpt.
I agree to the statement in this and in the other bug. The reported problem should very very likely only be related to the left over file psm.xpt. I believe removing only psm.xpt is the right decision. Not deleting the nppl3260.xpt file seems to make sense.
*** Bug 194073 has been marked as a duplicate of this bug. ***
so who can/should own this bug?
Based on comment #22, this will be fixed when the "depends on" bug 193241 is fixed. The bug was an installer bug, but I'll verify the proper behavior when installing 1.3b into the same directory as an existing 1.3a
bug 193241 has been fixed. this bug should also be fixed too.
Marking fixed. Will verify soon.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 194523 has been marked as a duplicate of this bug. ***
Whiteboard: fixed1.3
Verified.
Status: RESOLVED → VERIFIED
*** Bug 196752 has been marked as a duplicate of this bug. ***
*** Bug 203538 has been marked as a duplicate of this bug. ***
Product: PSM → Core
Version: psm2.4 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.