Firefox Loses Master Password on (RedHat) systems forcing usage of key3.db

VERIFIED FIXED in Firefox -esr60

Status

()

defect
P1
normal
VERIFIED FIXED
7 months ago
4 months ago

People

(Reporter: fbf1e8c7, Assigned: keeler)

Tracking

({dataloss, regression})

60 Branch
mozilla65
Points:
---

Firefox Tracking Flags

(firefox-esr6064+ fixed, firefox62 wontfix, firefox63 wontfix, firefox64 verified, firefox65 verified)

Details

(Whiteboard: [psm-assigned])

Attachments

(1 attachment)

(Reporter)

Description

7 months ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

Entered Master Password, shut down Firefox, and started Firefox the next morning.


Actual results:

Since last upgrade to 60.2.1 esr, master password is no longer there on startup.  I can recreate it but is is gone after next startup.


Expected results:

Master password should persist from one invocation to the next.
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 20181001135620

I've tested this report on Ubuntu 18.04 x64 using esr 60.2.1 and 60.2.0. I did not manage to reproduce the mentioned behavior. When master password is enabled before the update it did not disappear after the update for me. 

Do you have any add-ons installed on your Firefox?

Do this happen every time if you close and reopen the browser?
Flags: needinfo?(fbf1e8c7)
(Reporter)

Comment 2

7 months ago
It doesn't vanish if I just shut down and start up immediately.  However, if I leave the browser shut down for more than about five minutes, the master password disappears.

I just upgraded to 60.2.2 esr this morning.  Unfortunately that did not cure this behavior.  I have the following addons installed and all are enabled.

Adblock Plus
Blur
Cisco WebEx Extension
DuckDuckGo Privacy Essentials
FoxyProxy Standard
No Script
Privacy Badger
Web Developer

I found that if I delete or empty logins.json, the master password does not go away between restarts.  However, as soon I save an account from the dialog box and shutdown, the master password will be gone the next time I start firefox.

Unless you have another suggestion, my next step is to test with all my addons disabled.  That will have to wait until tomorrow.
Flags: needinfo?(fbf1e8c7)
I've re-tested this on different 'esr' versions using the above add-ons, but still cannot reproduce it. 

Are you still able to reproduce it in safe mode with all add-ons disabled?
Component: Untriaged → Page Info Window
Flags: needinfo?(fbf1e8c7)
(Reporter)

Comment 4

6 months ago
It may be this is Redhat specific. I see there is a report for the same behavior on Redhat bugzilla and they are testing a fix now.
Flags: needinfo?(fbf1e8c7)

Updated

6 months ago
Component: Page Info Window → Password Manager
Product: Firefox → Toolkit

Comment 5

6 months ago
(In reply to Phineas Fudrucker from comment #4)
> It may be this is Redhat specific. I see there is a report for the same
> behavior on Redhat bugzilla and they are testing a fix now.

Any chance you could paste a reference to RedHat bugzilla about this? I've got CentOS 7 with Firefox 60.2.2ESR and it looses master password and sync to Firefox Account along with all saved passwords. My other device is with CentOS 7 / Firefox 62 and it does not exhibit this behaviour.
Flags: needinfo?(fbf1e8c7)
(Reporter)

Comment 6

6 months ago
Here is the Redhat bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1633932
Flags: needinfo?(fbf1e8c7)
Thanks. So IIUC, bug 1475775 deletes key3.db even if NSS is configured to still use key3.db? Is that correct? Where is this getting fixed?
Status: UNCONFIRMED → NEW
Component: Password Manager → Security: PSM
Ever confirmed: true
Flags: needinfo?(kaie)
Keywords: dataloss, regression
Priority: -- → P1
Product: Toolkit → Core
QA Contact: past
Summary: Firefox Loses Master Password. → Firefox Loses Master Password on (RedHat) systems forcing usage of key3.db
We should probably at least make an effort to see if we're using the new DB before removing the old one.
Assignee: nobody → dkeeler
Whiteboard: [psm-assigned]
In bug 1475775, we added code to remove the old NSS key DB if the user has set a
password on the grounds that the old DB could potentially be unencrypted and
contain secrets. However, we did so with the assumption that we were using the
new DB, which is not necessarily true when the system has been configured to
always use the old DB, as with some RedHat products. This patch checks for the
existence of the new DB before proceeding with deleting the old DB. Technically
this isn't sufficient, because the new DB could be present even if we're not
using it. However, we've already gone far into "this configuration isn't
supported" territory.

Updated

6 months ago
Flags: needinfo?(kaie) → needinfo?(stransky)
Red Hat is going to fix that as a part of next Firefox ESR update this week:
https://bugzilla.redhat.com/show_bug.cgi?id=1633932#c27
Flags: needinfo?(stransky)
If Red Hat is fixing it downstream for now, it sounds like we can wait for ESR 60.4 instead of trying to rush it into a dot release.

Comment 13

6 months ago
Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2d51f2e8955b
check if we actually have a new key DB before removing the old one r=jcj

Comment 14

6 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/2d51f2e8955b
Status: NEW → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Flags: qe-verify+
Might this be good for uplift to 64 beta or is it better to let this change wait for 65?
Flags: needinfo?(dkeeler)
I'd like to see it uplifted, but I was also hoping to get QA verification on it before doing so.

Comment 17

6 months ago
Hi Phineas, We are running into some problems mounting our Red Hat images on Virtual Machines and it might take a while but in order to speed things up can you please re-test this issue using our latest Firefox Nightly you can find it here: https://nightly.mozilla.org and let us know if the issue still occurs, it will help us a lot. Thanks
Flags: needinfo?(fbf1e8c7)
This bug should be fixed by firefox-60.3.0-1 package on Red Hat side.
(Reporter)

Comment 19

6 months ago
My workstation is still at CentOS 6 so I downloaded the nightly build (65.0a1) onto a CentOS 7 virtual and tested from there.  The master password now does seem to survive restarts including a restart after a reboot.
Flags: needinfo?(fbf1e8c7)
I can imagine this same issue happening in more than just the "RedHat unexpectedly forced the old db format on Firefox", so yes, it would probably be good to uplift.
Flags: needinfo?(dkeeler)
This grafts cleanly to Beta and ESR60 as-landed. Please nominate it for approval when you get a chance.
Flags: needinfo?(dkeeler)

Updated

6 months ago
Duplicate of this bug: 1504276
Comment on attachment 9018758 [details]
bug 1496736 - check if we actually have a new key DB before removing the old one r?jcj

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: Bug 1475775

User impact if declined: Users can lose passwords stored on systems that configure NSS in a way we don't expect.

Is this code covered by automated tests?: Yes

Has the fix been verified in Nightly?: Yes

Needs manual test from QE?: No

If yes, steps to reproduce: 

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): This is a safer version of what we did in bug 1475775 (i.e. try to check that we successfully upgraded before removing the old db)

String changes made/needed: 

[ESR Uplift Approval Request]

If this is not a sec:{high,crit} bug, please state case for ESR consideration: Loss of stored passwords on some systems.

User impact if declined: Users can lose passwords stored on systems that configure NSS in a way we don't expect.

Fix Landed on Version: 65

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): This is a safer version of what we did in bug 1475775 (i.e. try to check that we successfully upgraded before removing the old db)

String or UUID changes made by this patch:
Flags: needinfo?(dkeeler)
Attachment #9018758 - Flags: approval-mozilla-esr60?
Attachment #9018758 - Flags: approval-mozilla-beta?
Comment on attachment 9018758 [details]
bug 1496736 - check if we actually have a new key DB before removing the old one r?jcj

dataloss fix for some nss configurations, approved for 64.0b8
Attachment #9018758 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment on attachment 9018758 [details]
bug 1496736 - check if we actually have a new key DB before removing the old one r?jcj

OK for uplift to 60.4.0esr, seems worth fixing to avoid user data loss.
Attachment #9018758 - Flags: approval-mozilla-esr60? → approval-mozilla-esr60+

Comment 27

5 months ago
Verified on Cent OS x64
Version: 65.0a1
Build ID: 20181112100105

Comment 28

5 months ago
Verified on Cent OS x64
Version: 64.0b9
Build ID: 20181112164519
Status: RESOLVED → VERIFIED
Flags: qe-verify+
See Also: → 1508149
The existence of file key4.db doesn't guarantee that the secret key contents of file key3.db have already been successfully migrated, see bug 1510212.
Setting needinfo for keeler, just to ensure you see comment 30.
Flags: needinfo?(dkeeler)
Ok - thanks. So it sounds like NSS is the right place to fix this. Is there already a bug filed for addressing this?
Flags: needinfo?(dkeeler)
You need to log in before you can comment on or make changes to this bug.