After downgrading to firefox-60.2.0-1.el7_5.x86_64 the above test works ok.

What happens if you omit the `--new-instance` from subsequent invocations?

(In reply to Ken Coar from comment #4)
> What happens if you omit the `--new-instance` from subsequent invocations?

This has no effect either way, --new-instance was used to underline that the "regular" firefox process using ~/.mozilla or such is not involved in the test in anyway:

$ firefox --help
...
  --new-instance     Open new instance, not a new window in running instance.

Seems that this happens only if a master password is used.

Upstream bugzilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=1475775

I have the same problem. I have a master password set.

What seems to be happening is that the key3.db file gets deleted when Firefox is launched. If the file is present on startup, it will correctly load the saved logins, but it will then delete the key3.db file and the next time Firefox is run, there will be no saved logins (and no master password set).

The logins.json file remains intact, but the key needed to decrypt the usernames and passwords is lost.

If the old key3.db file is restored, it will work again, but only the first time, after which the file is deleted again.

This is almost certainly related to bug 1625531. 
The upstream bug mentioned above was due to the fact that Firefox left the old key3.db file when it upgraded it to key4.db. However, from my tests, it seems that in the RHEL version of Firefox, the NSS files (key3.db, cert8.db and secmod.db) are never upgraded to the newer versions. Even with a fresh Firefox profile, it still creates a key3.db file.

If I run firefox after setting the following environment variable:

$ export NSS_DEFAULT_DB_TYPE="sql"

then it creates the new NSS files (key4.db and cert9.db). 
It seems that NSS in RHEL is configured differently from the upstream version and this might be causing the problem.

Indeed, I need to set NSS_DEFAULT_DB_TYPE=sql to get certutil to create key4/cert9.db files.  I've not yet figured out how to convert an old pre-60.2.1 profile passwords to work with 60.2.1.

(In reply to Vladan Bato from comment #9)
> If I run firefox after setting the following environment variable:
> 
> $ export NSS_DEFAULT_DB_TYPE="sql"
> 
> then it creates the new NSS files (key4.db and cert9.db). 
> It seems that NSS in RHEL is configured differently from the upstream
> version and this might be causing the problem.

Kai, do you know if we have a different NSS config at RHEL? Thanks.

(In reply to Martin Stransky from comment #13)
> (In reply to Vladan Bato from comment #9)
> > If I run firefox after setting the following environment variable:
> > 
> > $ export NSS_DEFAULT_DB_TYPE="sql"
> > 
> > then it creates the new NSS files (key4.db and cert9.db). 
> > It seems that NSS in RHEL is configured differently from the upstream
> > version and this might be causing the problem.
> 
> Kai, do you know if we have a different NSS config at RHEL? Thanks.

I believe it's related to Bug 1503632. We should make sure the fix works also with the old db format, used in RHEL7/6.

Yes, this seems to be caused by disabled NSS database migration which was proposed by NSS team at Bug 1503632.

We need to decide if we want to enable the migration or dsiable the old database removal (that can lead to data leak - CVE-2018-12383, https://bugzilla.mozilla.org/show_bug.cgi?id=1475775).

There's an update from Kai here:

No, the old format isn't compromised.

The upstream report depends on the following series of events:
- user has saved logins
- user has NO master password
- user upgrades to a thunderbird that uses sql by default,
  the NSS database is migrated
- user decides to set a master password

With this scenario, the new sql storage (key4) is password protected,
but the pre-migration storage (key3) remains unprotected.

In other words, the issue is that an unprotected backup file remains in
storage.

This scenario cannot happen with the firefox and nss packages that we
distribute on RHEL 6 and RHEL 7, because we don't migrate to sql. If the
user sets a password on rhel 6/7, the dbm storage will be password
protected.

If you decided to migrate on rhel 6/7, you'd INTRODUCE the described
issue to rhel 6/7.

Kai


On 10/9/18 3:12 PM, Martin Stransky wrote:
> Kai,
>
> looks like the old profile can be compromised:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1475775
>
> thus mozilla decided to clear the old data which means our non-migrated
> profile is ripped off and users are loosing data (when master password
> is used):
> https://bugzilla.mozilla.org/show_bug.cgi?id=1475775#c51
>
> I think we should allow the migration as the original format is
> compromised. Is there any reason to stay with the old format?
>
> Thanks,
> ma.

We need to revert he patch from https://bugzilla.mozilla.org/show_bug.cgi?id=1475775

Martin,

this dataloss bug seems real and bad. This is the real issue that you have in RHEL 6 and 7.

The new Mozilla deletes the key3.db storage file which we are still using in RHEL 6+7.

I recommend that you push out a new update to the firefox package, which reverts the upstream patch and doesn't delete key3.db.


My comment 16 was related to the potential leftover of an unprotected file on RHEL 6+7. This is the issue that we don't have in RHEL 6+7, because we keep using key3.db

(In reply to Martin Stransky from comment #17)
> We need to revert he patch from
> https://bugzilla.mozilla.org/show_bug.cgi?id=1475775

agreed

The problem also exists in CentOS 6. After upgrading to firefox-60.2.1, I lost  all my logins saved in the last 10+ years

Unofficial src.rpm package with a fix can be downloaded here:
http://people.redhat.com/stransky/firefox/firefox-60.2.2-2.el7_5.src.rpm

Martin, thanks for the package with the proposed fix.  I used mock to build for x86_64 and can verify the fix is as expected...no more data loss.

Hard to ask without sounding greedy, but is there an EL6 srpm?

(In reply to Chris Schanzle from comment #24)
> Martin, thanks for the package with the proposed fix.  I used mock to build
> for x86_64 and can verify the fix is as expected...no more data loss.
> 
> Hard to ask without sounding greedy, but is there an EL6 srpm?

EL6 srpm is the same as EL7_5 - just build it on RHEL6.

Thank you again.  I'm pushing out updates tonight and was hoping to get an EL6 build done today.  The error I got building for EL6:

Error: No Package found for rust-toolset-7-cargo
Error: No Package found for rust-toolset-7-rust

I don't find those packages for EL6 and the firefox.spec unconditionally sets

%global use_rustts 1

I changed 1 to 0 and at the "./mach build -v" stage (~20 mins in), failed to build with "ERROR: Rust compiler not found."

No worries, I'll wait for the official packages.

(In reply to Chris Schanzle from comment #26)
> Thank you again.  I'm pushing out updates tonight and was hoping to get an
> EL6 build done today.  The error I got building for EL6:
> 
> Error: No Package found for rust-toolset-7-cargo
> Error: No Package found for rust-toolset-7-rust
> 
> I don't find those packages for EL6

They're available for RHEL6, you may need different subscription or so - I really don't know but we use them to build official RHEL6 packages.

> No worries, I'll wait for the official packages.

This may be released as a part of next security update which is planned to 2018-10-23 (https://wiki.mozilla.org/Release_Management/Calendar)

It looks to me like the new firefox-60.4.0-1.el7 that was just released has re-introduced this bug after it was fixed in the previous releases at the end of RHEL-7.5.

I'm not seeing any issues with it.

The patch that was added to fix this issue in firefox-60.2.2-2.el7_5 has been removed (mozilla-1475775-key3-revert.patch) .. and the code that was removed by that patch (in firefox-60.4.0/security/manager/ssl/nsNSSComponent.cpp ) in the tarball is still there in this new version.  So unless something else was changed in the way the package builds .. the code to 'delete old dbm database DBs' has been reintroduced into firefox-60.4.0/security/manager/ssl/nsNSSComponent.cpp.

This should be fixed in 60.4 esr by deleting key3.db only when key4.db exists, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1496736
Do you see still the problem?

I had more than one CentOS user report that they lost their databases .. BUT .. I will test/troubleshoot it today and verify.  I just noticed that the patch was removed and had those reports, so I wanted to make sure it was on purpose.

Under normal circumstances, this should be OK now.  

In the case of the people reporting issues, somehow they had both the newer and older DBs present on their systems .. so it erased the older one.  

Not exactly sure how they ended up with both versions.  So, it seems only corner cases that are impacted unless there is an easy way to have both DB types.  I would think this would be accomplished by having used a mix and match of installing the mozilla version of firefox at some point and then converting back to our rpm version later.

So unless this becomes more wide spread, sorry for the noise.