- #Current version of firefox 52.9 manual
- #Current version of firefox 52.9 full
- #Current version of firefox 52.9 code
- #Current version of firefox 52.9 password
Please refer to one of the following calendars for up-to-date scheduling: This wiki page may not always have the most current information. Thunderbird tracks the ESR schedule column per Thunderbird release info.
#Current version of firefox 52.9 manual
The release to users may be a few days later, to allow for manual testing and sign-off.
#Current version of firefox 52.9 code
Code is not always released to users on the same day as the branch migration. Future dates may change if the process changes. library=/usr/lib/x86_64-linux-gnu/nss/libnssckbi.This schedule is based on the current RapidRelease plan. NSS=Flags=moduleDBOnly,internal,critical trustOrder=75 cipherOrder=100 slotParams=(1= Flags=internal,critical parameters=configdir='sql:/home/USER/.pki/nssdb' certPrefix='' keyPrefix='' secmod='secmod.db' flags= updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid='' updateTokenDescription=''
Dana knows much more about the NSS/PSM side.ģ years Thanks for pointing me into the right direction with "pkcs11.txt" - the problem seems to be Changes between old and new file: NFS and the environment variable NSS_DEFAULT_DB_TYPE could also be relevant to your investigation. You should read the two bugs mentioned there and look at the timing of bug 783994 to help solve this. The only changes are related to the encryption that Dana mentioned in comment 5.
#Current version of firefox 52.9 password
There have been no changes to password manager storage that I can think of. > 52->60 upgrade, but there are other reports where this caused no problem > The bug was originally filed by someone who lost his passwords after the It didn't make sense to support downgrades on a profile that never previously used the old version. if you have no ke圓.db, only key4.db, then logins can only be decrypted in TB60+. It's expected that logins saved in a new profile created after bug 783994 (defaulting to key4.db) will not be able to be read in an older build expecting ke圓.db. I had no problems with the former ( comment #11), but others > We have contradicting reports of problems when switching from TB 52 to TB 60 (In reply to Jorg K (GMT+1) from comment #22) (In reply to Wayne Mery (:wsmwk) from comment #16) If I enter them again, then they become available in 52, 60 and 64. If I create a profile with TB 64 beta (or TB 65 Daily), then the passwords are not accessible in TB 52. The failing profile wasn't new, it had been created with TB 65 Daily.
#Current version of firefox 52.9 full
I wasn't drunk when I wrote comment #4, but I didn't tell the full truth. So on a new profile, I don't see any problem whatsoever. All still working.ĥ) I went in with TB 64 beta. Passwords visible in PW manager.Ĥ) Went back with TB 60.3. That is my experience from upgrading two people (friend/family).ģ) Went back to the profile with TB 52. So a regular user just moving from TB 52 to TB 60 will NOT have any problem. I could visit my IMAP folders, the PW manager showed the saved passwords.
I did NOT get prompted to enter the password again, All good.Ģ) Visited profile with TB 60.3. 10/18 Win (constant issue for user, not just updates)ġ) Created profile with TB 52, setup account, saved password.Ĭhecked saved passwords in PW manager. 10/24 Mac (user had NOT updated to 60.x)
10/17 linux, downgrade from 60.2.1 to 52.x and passwords work And cannot rule out OS specific.Ĭasting a wide net for potential support postings - some of these sound similar to this bug report, others not so much: I think THIS issue is unlikely to be OS specific. My key question is whether only 52>60.3.0 is affected? Or is 60.2.1 also affected?Īnd as Jorg asks, under what circumstances?Ĭalling this dataloss until we know better. Can someone else reproduce this? (copying some of our giant testers)
0 kommentar(er)
