Closed Bug 1789213 Opened 2 years ago Closed 1 year ago

Passwordmanager empty after upgrade to Version 102 with profiles on network filesystem drives / NAS and hardware acceleration

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Version:
Thunderbird 102
Platform:
Unspecified
Windows
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: axel, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [fixed by newer Synology OS, DSM 7])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0

Steps to reproduce:

Upgraded Thunderbird from 91 to 102.2.1. Profiles are on a mapped drive (connected using a different user/password). Open Thunderbird after the upgrade.

Actual results:

Thunderbird asks for all passwords, but these passwords were all stored in Thunderbird before. Passwordmanager shows an empty list of passwords. It is impossible to save passwords.
Further hints: I copied a profile to a local drive before it was opened with TB 102.2.1 I added a profile with this local Profile to Thunderbird 102. Passwords were all there, all worked as expected. After copying this profile back to the mapped drive, my computer can still open this profile without any errors, but if this profile is opened with another computer on our network, the passwords are all missing.

Expected results:

Passwords should be still there, if a profile from a mapped drive is openend with Thunderbird 102.2.1

I don't know if this kind of copying is expected to work. Maybe a file permission problem, or a parallel access problem.

Component: Security → General
Summary: Passwordmanager empty after upgrade to Version 102 with profiles on mapped drives → Passwordmanager empty after upgrade to Version 102 with profiles on network filesystem drives

It is impossible to save passwords.

So what happens? Any errors on the error console? (Ctrl+Shift+J)

Dear Magnus, I have the following errors (after starting Thunderbird 102.2.1 with a profile located on a mapped network drive. I added the password with the save the password option for the first two password requests and skipped the password request for the third e-mail account):

NS_ERROR_FAILURE: Couldn't decrypt string 2 crypto-SDR.js:200
decrypt resource://gre/modules/crypto-SDR.js:200
_decryptLogins resource://gre/modules/storage-json.js:846
findLogins resource://gre/modules/storage-json.js:705
findLogins resource://gre/modules/LoginManager.jsm:513
_promiseAuthPrompt resource:///modules/MsgAsyncPrompter.jsm:54
_promiseAuthPrompt resource:///modules/MsgAsyncPrompter.jsm:52
run resource:///modules/MsgAsyncPrompter.jsm:77
InterpretGeneratorResume self-hosted:1422
AsyncFunctionNext self-hosted:632
NS_ERROR_FAILURE: Couldn't decrypt string 2 crypto-SDR.js:200
NS_ERROR_FAILURE: Couldn't decrypt string 2 crypto-SDR.js:200
NS_ERROR_ABORT: User canceled primary password entry 4 crypto-SDR.js:90
NS_ERROR_FAILURE: Couldn't decrypt string 2 crypto-SDR.js:200
NS_ERROR_FAILURE: Couldn't decrypt string 2 crypto-SDR.js:200
NS_ERROR_FAILURE: Couldn't decrypt string 2 crypto-SDR.js:200
NS_ERROR_ABORT: User canceled primary password entry 4 crypto-SDR.js:90
NS_ERROR_FAILURE: Couldn't decrypt string crypto-SDR.js:200
NS_ERROR_FAILURE: Couldn't decrypt string crypto-SDR.js:200
NS_ERROR_UNEXPECTED

We have several users in our network and this is happening to all of them after upgrading to Thunderbird 102.2.1

(In reply to Kai Engert (:KaiE:) from comment #1)

I don't know if this kind of copying is expected to work. Maybe a file permission problem, or a parallel access problem.

Dear Kai, I know that this kind of copying is not intended. I only used it for a further examination what might have happened. As we have 15 users using profiles on a mapped network drive (each user has one profile, of course) since years without problems and we have this problem with each user who updated to 102.2.1, it might be a problem with the 102.2.1 Version.

I just did some more tests: If a mapped drive in the same domain (mapped with the same user as in the OS) is used, we do not have this problem. The problem only occurs, when we use a share of our NAS (mapped with different user credentials: A user/password from another domain) for the storage of the profile. As said before, we were using this setup since years without problems.

What kind of account is it? IMAP or POP?

(In reply to Magnus Melin [:mkmelin] from comment #6)

What kind of account is it? IMAP or POP?

We only have IMAP accounts

Hello,
I have the same Problem. I used TB years ago with no problem and stored the profiles at my Synology NAS and access from different Windows 10 PC to the profiles in my own Network (only one profile can be used from one PC at the same time). The drive is shared as a networkdrive from the Windows PC and the NAS has a fixed IP Adress. Now my Windows TB installation updated at 102.2.2 and always after the first start, TB asked all passwords. It is not possible to save the password with the passwordmanager (the table is empty), only while I use TB the passwords would be remember and I can get my emails. After I closed TB and start it new, I must enter passwords again. After I transfered one profile to the internal drive of the PC it works normal and I can use the passwordmanager to store the passwords. I use either pop and imap accounts and also calendars at network (Synology/Nextcloud) and Google Calendars it is also the same problem with the passwords.
Maggi.

Someone who can reproduce this should run mozregression.

Sorry,
but i am only a normal user... What is this mozregression, i watched the video but i t looks like a tool to find version that are compatible or some, or is it a tool to log ? I will help to solve it but what can I do?
Regards MAggi

(In reply to b1 from comment #9)

Someone who can reproduce this should run mozregression.

I can do this, I will come back with the result (later today).

Some tips: Mozregression allows you to use a fixed profile, the one you set up on the network drive. If it worked in 91 and doesn't work in 102, the bisection range according to https://wiki.mozilla.org/RapidRelease/Calendar is 91 Start: 2021-05-31 102 End/103 Start: 2022-05-30. You should be able to bisect this in 9 or 10 steps. Since likely a change in the Mozilla platform code caused the issue, it would be best to reproduce it in Firefox, where you can also store site passwords. That may enable you to pin down the regression better since the tool will use FF builds and not TB builds. But never mind, please use what works best for you.

I got the same Problem, if i don't tick save password I can download my mail, saving the Pasword is not possibel and doesn't pick up my mails.

Did you use the "Tools / Import" menu to import data from a different profile?

HI,
so I tried now different things.
First I used the Mozregression with an existing profile that is hint about the problem, with the last 4 steps to the actual date. It works with all. At Mozregression I used "clone" to use the existing profile to run mozregression.
After this I create a new profile at network drive (at the same directory whre the other profiles stored) and connect to the same mailrpovider as one old profile. I enter the Username/Password and email adress and TB stored this password correct. I see the passwords under Option/security in the table. After I closed TB and re open ist the passwords are still saved an visible and i can use it to download mails. So I copied the mail directory from the old profile in this new profile directory it also works with all old mails......
But when I copied all files and directories (without the login.josn file) from the old to the new profile then there is no passsword anymore and TB asked about the passwords after starts.
If it so work, that I can create an new profile with the same User as it is stored in the old profile, I would try it to copy only the Mail Directory in the new profile. But my other Profile i used that is also hint about the problem, (there are some extensions and calendars and so on), I belive this would be to difficult to solve it like this .....

I'm sorry, but comment 15 isn't easy to understand. Can you please explain what you want to say with "is hint about the problem"?

Your comment sounds like you are taking a subset of files from one profile, and copying them into another profile directory, only replacing some of the files.

If this is what you do, this isn't guaranteed to work. There are interdependencies between files, and if you mix files from different profiles, without fully understanding those interdependencies, it's very easy to end up with a broken, inconsistent profile, and I think we cannot help you with such a mixed profile.

For example, if you mix file key4.db from one profile with file logins.json from another profile, it's absolutely expected that your password store is broken.

I am sorry but it is not so easy to translate my opinions to english language....
I tried mozregression with an existing profile at networkdrive with the last 4 versions until to 13.09.2022 and all saved the password correct, also the newest version 102.2.2. Question: What are the differens between "clone", "clone-first" and "reuse", I used "clone" to test it with mozregression. Could it be a reason why at mozregression the passwords are correct shown under otions/security independ the versions?
If I create a new profile with an exisitng email account, the passwords will be stored/saved also at a network drive, also after restart TB. Also, if I copy the mail folder from an old exisitng profile to this new profile at networkdrive the passwords will be saved correct.
The exisitng old profile that was updated long times ago (more than 5 years) with different TB versions doesnot store passwords if I click "save with password manager" with since the newest TB Version was updated. If I do not click "save with password manger" button, only enter the password an click "ok", it works temporarly until I end TB. After restart passwords are dissappeared.

(In reply to b1 from comment #12)

Some tips: Mozregression allows you to use a fixed profile, the one you set up on the network drive. If it worked in 91 and doesn't work in 102, the bisection range according to https://wiki.mozilla.org/RapidRelease/Calendar is 91 Start: 2021-05-31 102 End/103 Start: 2022-05-30. You should be able to bisect this in 9 or 10 steps. Since likely a change in the Mozilla platform code caused the issue, it would be best to reproduce it in Firefox, where you can also store site passwords. That may enable you to pin down the regression better since the tool will use FF builds and not TB builds. But never mind, please use what works best for you.

Ok, Itested it: If you use "clone" for the profile, then you can't reproduce the problem. I then used "reuse" for the profile and I could narrow it down:
2022-09-15T13:31:26.639000: INFO : Narrowed nightly regression window from [2022-03-04, 2022-03-06] (2 days) to [2022-03-05, 2022-03-06] (1 days) (~0 steps left)
2022-09-15T13:31:30.958000: DEBUG : Found commit message:
Bug 1670791 - Fix minor spelling errors. r=mkmelin

Differential Revision: https://phabricator.services.mozilla.com/D140440

2022-09-15T13:31:30.960000: INFO : The bisection is done.
2022-09-15T13:31:30.962000: INFO : Stopped

I also checked it with restored profiles from my back-up: The Build from 2022-march-05 works and with the build from 2022-march-06 the password manager "lost" the passwords.

These are the relevant ranges:
https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2022-03-05&enddate=2022-03-07
https://hg.mozilla.org/comm-central/pushloghtml?startdate=2022-03-05&enddate=2022-03-07
Looking after midday on 2022-03-05 when the apparently working 2022-03-05 Daily was built.
In the comm-central range you can see D140440 (Bug 1670791 - Fix minor spelling errors).

We don't see anything related to passwords, file storage, network, etc. All those changes are in the area of graphics, rendering, etc. Maybe we're missing something. Have you confirmed with these builds?
http://ftp.mozilla.org/pub/thunderbird/nightly/2022/03/2022-03-05-09-50-26-comm-central/
http://ftp.mozilla.org/pub/thunderbird/nightly/2022/03/2022-03-06-10-50-05-comm-central/

(In reply to b1 from comment #20)

These are the relevant ranges:
https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2022-03-05&enddate=2022-03-07
https://hg.mozilla.org/comm-central/pushloghtml?startdate=2022-03-05&enddate=2022-03-07
Looking after midday on 2022-03-05 when the apparently working 2022-03-05 Daily was built.
In the comm-central range you can see D140440 (Bug 1670791 - Fix minor spelling errors).

We don't see anything related to passwords, file storage, network, etc. All those changes are in the area of graphics, rendering, etc. Maybe we're missing something. Have you confirmed with these builds?
http://ftp.mozilla.org/pub/thunderbird/nightly/2022/03/2022-03-05-09-50-26-comm-central/
http://ftp.mozilla.org/pub/thunderbird/nightly/2022/03/2022-03-06-10-50-05-comm-central/

Build 20220305095026 is working without this error
Build 20220306105005 has the error (empty password manager)

Can someone else please confirm the findings and look at the regression range.

Probably dupe of bug 1780941, where someone found setting layers.acceleration.disabled to true fixes it.
If that's the case, likely fallout from the graphics changes

See Also: → 1780941

I can confirm that setting layers.acceleration.disabled to true and restart thunderbird fixes the problem. All passwords are now back in the password manager and also used automatically for the e-mail accounts.
It seems, that you can even switch back this setting to false later on, but this was only a short try.
Thank you very much for this fix!
Let me know, if I can help you with further tests for this bug.

i can confirm switching setting "layers.acceleration.disabled " to true fixes the problem, but switching it back to false didn't work for me.
Many Thank for the fix, the Bug geve me a real headache the last two days.

(In reply to Magnus Melin [:mkmelin] from comment #23)

Probably dupe of bug 1780941, where someone found setting layers.acceleration.disabled to true fixes it.
If that's the case, likely fallout from the graphics changes

Weird that graphics changes affect the storing of passwords. Emilio was involved in the reviews, so perhaps he has an idea. Bug 1780941 could be duped here since this bug here found the regression range (comment #20). Is the bug not reproducible in FF alone, that stores passwords, too.

Flags: needinfo?(emilio)

i can also confirm switching setting "layers.acceleration.disabled " to true fixes the problem...
thanks a lot....

See Also: 1780941 →

(In reply to b1 from comment #26)

Flags: needinfo?(emilio)

Errr... Wait what? Talk about bizarre bugs...

Is this OS specific (windows-only per the ua string in comment 0)? If so you can discard a lot of the changes in that range. It'd be interesting to know if someone can pull up the inspector and see if the passwords are there (just not rendered) or the error is somewhere in the TB code (comment 3).

If the later, it's probably some sort of timing issue because if not I don't see how otherwise any mozilla-central change there could be remotely related.

Windows users are in the 95% majority (4% Mac, 1% Linux, see stats), they are also more likely to mess around with network drives and so-called drive letters. Apparently so far no reports on Mac/Linux.

All reports say that passwords need to be entered again, so it doesn't appear to be a display issue. It sounds more an initialisation issue of the password manager, no passwords retrieved or stored. Disclaimer: Just a guess.

This is not easy to reproduce. Here's what we tried.

Test 1: On PC 1, created and shared a folder. On PC 2, created a profile into the shared folder, using both UNC path (\\server\folder) or drive letter. No problem seen, account passwords are in password manager.

Test 2: On PC 1, enabled Administrator account, created and shared folder. On PC 2, mapped this folder onto a network drive using credentials of the Administrator of PC 1, got prompted for the password. Created a profile into the shared folder. Logged out from PC 2, logged in again, entered password for network drive to get it connected again. Started TB again, no problem seen, account passwords are in password manager.

Comment #0 mentions a mapped drive, so a drive letter, and a different user on the "server" machine. However, comment #3 also mentions a primary (formerly: master) password. We tried that also and saw no problem. So what are the exact instructions to reproduce the issue?

But 1780941 comment #0 is not mentioning details, particularly doesn't mention a different user since there a NAS is used (which may or may not have special authentication). That comment also mentions problems only after an update (Quote: I tried to make a new profile. Then it worked, but only until next update).

I hope I can give you some useful details:
We only have Windows 10 Clients in an active directory domain (Windows Server 2008 R2, Domain 1). If we use mapped drives from this Server or local drives (for the storage of the profile folder), we do not have problems. If we use a mapped drive from our Synology NAS (which is no member of our Domain 1, but a member of our Domain 2 (SAMBA AD Domain), we run into this problem. Mapping was done using a user/password from domain 2.
Comment 8 also reported a Synology NAS, but this manufacturer is quite common.

So the test in comment #32 is essentially mapping a drive from another (server) Windows box onto a client Windows machine. According to comment #33 this works for you. To produce the error, it needs to be some sort of NAS, also mentioned in bug 1780941 comment #0. Now you need to find a developer with a NAS :-( - Is this a case for TB's enterprise support?

Flags: needinfo?(bugzilla2007)

P.S.: Someone should edit the bug summary to include NAS and mention the workaround from bug 1780941 which is switching off hardware acceleration.

P.S.2: Please check whether this is reproducible in Firefox alone: 1) Place a Firefox profile onto a NAS drive 2) Check whether site logins are stored. Or maybe FF is using a different mechanism these days?

Would the following test be helpful?:
I could create a share on my Linux Server in Domain 2 and test if we run into the error, if I store the profile folder there and use it as a mapped drive (for a user of Domain 1).
If not, it might be a specific problem with the NAS (maybe even Synology specific). If we see the error, it might be a problem with the two domain/different user setup or with SAMBA.
I'll test it on Monday.

(In reply to b1 from comment #36)

P.S.2: Please check whether this is reproducible in Firefox alone: 1) Place a Firefox profile onto a NAS drive 2) Check whether site logins are stored. Or maybe FF is using a different mechanism these days?

I'll check that on Monday , too

(In reply to b1 from comment #36)

P.S.2: Please check whether this is reproducible in Firefox alone: 1) Place a Firefox profile onto a NAS drive 2) Check whether site logins are stored. Or maybe FF is using a different mechanism these days?

I checked it, this bug seems to be thunderbird specific. I copied an old Firefox profile onto the NAS (the same NAS as used for the Thunderbird profiles). I tried different Firefox builds (before and after march the 5th 2021) with mozregression. Even the most recent builds work without this bug.

(In reply to Axel Lang from comment #37)

Would the following test be helpful?:
I could create a share on my Linux Server in Domain 2 and test if we run into the error, if I store the profile folder there and use it as a mapped drive (for a user of Domain 1).
If not, it might be a specific problem with the NAS (maybe even Synology specific). If we see the error, it might be a problem with the two domain/different user setup or with SAMBA.
I'll test it on Monday.

I tried to test it, but I have random results now. Seems to be a side effect of changing the layers.acceleration.disabled to true. After switching back to false, I have instable results (when I try to trigger the bug) and no idea, why the bug is there or not (I only tested scenarios, where the bug was triggered before). Switching this setting to true is still a stable fix for this bug. Sadly, I can't reliably test, if the NAS itself was causing the bug.

Flags: needinfo?(bugzilla2007)
Summary: Passwordmanager empty after upgrade to Version 102 with profiles on network filesystem drives → Passwordmanager empty after upgrade to Version 102 with profiles on network filesystem drives / NAS
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression

IIUC all affected users are on Windows, please correct me if I'm wrong.

OS: Unspecified → Windows

Adding NSS developers.

We have a strange behavior that saved passwords (NSS SDR) are unaccessible when using Windows and hardware acceleration and files being stored on a network drive. Apparently all of these conditions must be true in parallel to experience the bug.

Can you imagine some sort of NSS timing behavior, that would be influenced by these conditions? It's a regression in TB 102.x (NSS 3.79.1), and it was working apparently with TB 91.x (NSS 3.68.4). Is there new NSS encryption assembler code that could be responsible? Or could it be related to the key4.db sqlite storage, which usually does many disc accesses?

Summary: Passwordmanager empty after upgrade to Version 102 with profiles on network filesystem drives / NAS → Passwordmanager empty after upgrade to Version 102 with profiles on network filesystem drives / NAS and hardware acceleration

One possible case could be trashed integrity checks. All encrypted data has integrity checks, but in 3.68 and earlier, those checks were not propertly checked. in 3.69/3.70 those checks were added, but we found a case where the checks weren't being stored under the correct labels (An update case, where the checks were moved to incorrect labels). The current code should detect those two cases, but maybe you are running into another case where something has eaten the integrity checks (or they weren't properly added).

But you say it's hardware acceleration + network drive, so I'm note sure how that would cause the checks to fail or be corrupted.

Thanks Bob for this theory. It's an interesting hint.

I've looked at NSS release notes, I could find only one bug that directly mentions the type of change you mentioned: bug 1720226.

Would it be safe to backout that change, for an experimental build? "Safe" meaning "not worse than 3.68"?

I could create an experimental build with that patch backed out, and we could ask affected users to test if it solves the problem for them.

Bob, please see the previous comment. Thanks in advance for your feedback.

I created an experimental comm-esr102 build, with bug 1720226 backed out:
https://hg.mozilla.org/try/rev/a2befcf030ba3e8804f5cdd8dda5414387c3bfda

Flags: needinfo?(rrelyea)

It's a shot in the wild, but another potential experiment could be to backout bug 1720227 (performance measuring on a network drive would likely result in different results than measuring locally, so that patch could potentially have a side effect).

I have had the same issued as described above after a 102.x upgrade from a 91.x using a NAS based profile with different NAS accounts from the Windows 10 account. The passwords were no longer saved though they would work for a session. Unchecking hardware acceleration and the saved passwords would magically reappear. Check hardware acceleration and they were gone.

Same issue arose after I installed Betterbird, created a new profile and later upgraded Betterbird

Jörg touched base with some TB developers and they prepared test build (above). I unpacked the target.zip, fired up thunderbird and pointed it at one of my profiles. Mail was delivered and passwords were saved and visible even with hardware acceleration checked. Looks like they're on to something.

perinipm, thank you for testing.

If I understand correctly, you're reporting that the test build from comment 50 fixes this bug for you?

That is correct - as far as it goes.

Trying to find a solution, I was introduced to Betterbird.

I installed Betterbird 102.2.1 and upgraded to the 102.3.1 and noticed I could no longer save passwords. Backed that out and later upgraded to 102.3.2 to see if the problem persisted. Still saw the same issue which given how close the code base is between the TB and BB it is likely a 1xx "feature" and wasn't the result of a profile conversion corruption going from TB 9x to 102x.

The test build did not have this issue though neither did Betterbird when initially installed and using a new profile. The problem was visible when using the old profile converted from 9x but another issue was most likely the culprit there. It wasn't until I was able to isolate and delete the password files from Tbird (logins.json, key4.db and cert9.db) that I was even able to connect within a session let alone save passwords.  

But with the new profile AND upgrading to Betterbird 102.3.1 I could no longer save those passwords.

So while the problem wasn't apparent in the test build, I'd suggest that the problem's disappearance from an upgrade would inspire more confidence.

Hope this helps.

pat

Short clarification: Patrick (perinipm) contacted our support and we pointed him to this bug and the test builds to expedite the solution for everyone. Hopefully the reporter and other affected users will test soon.

Sorry that I wasn't clear.
Wndows 10; Synology NAS profiles
Started with TB 9x to 102x upgrade. Couldn't connect to mailservers or save passwords. Suspected 10+ year profile became corrupted. While trying to get to valid connection state i.e password working for a session, I came across Betterbird.
Installed 102.2.1, and created a new profile. Connection and saving of passwords worked. Using Betterbird with old profile did not fix the previous symptoms.
Upgraded Betterbird to 102.3.1. No longer saving passwords but could connect for a session to mailservers.
Uninstalled 102.3.1. Installed 102.3.2. Connections and password saving worked.
From Tbird 102.x using old profile deleted profile password files and was able to connect to mailservers for session.
Unchecked the hardware acceleration setting under settings\general, restarted and previously "saved" passwords appeared (as well as still being able to connect to mailerservers
Fired up Betterbird, unchecked hardware accleration and restarted. Passwords were now available.
Downloaded the test build portable version and fired up Tbird, pointed to old profile with hardware acceleration checked and everything was still good.
The Betterbird sequence suggests that 10x in place upgrades may be the problem (at least to me). The corrupt password files (probably from the profile conversion) clouded insight.

You'd need to do a 10x in place upgrade to really repeat the behavior

Everyone affected by this bug:

The developers cannot currently reproduce this bug.
We need your collaboration, and testing the experimental build is a way to do so.

We need more than one report.

Glad to help. I can repeat the loss of passwords just by toggling the hardware acceleration setting. I did this in both your test build and a betterbird installation. I upgraded betterbird to 102.3.3 and since in the original settings hardware acceleration had been toggled off, there was no problem with the passwords. Toggling hardware acceleration back on and the password save disappears.

I also turned off hardware acceleration in Betterbird and started the test build. The passwords were gone. I turned off HA and restarted the test build and passwords were back.
So, it seems to be a 10x feature for those of us using a NAS profile. I use the same account name for both windows and the NAS - different passwords. Not that that should really matter.

perinipm: You had already provided feedback, thanks.

I'd like to ask for feedback from an additional person who experiences this bug. Thanks in advance.

(I'd also like to say that comments about betterbird are not really relevant in thunderbird bugzilla, we're not tracking what betterbird does, and a test with betterbird doesn't mean much for thunderbird's behavior.)

Using a 9x to 10x Tbird profile and Tbird 102.3.2 I can also toggle password access on and off with the HA switch. No need to repopulate passwords.

To Kai (?I think)
I am one of the people who reported this problem and do keep my profile on a NAS. I would be happy to try out something, but I am not clear what you would like me to try (I admit to not following the bugzilla emails very closely once my own problem was solved).

Right now I am running 102.3.1 32bit, and toggling hardware acceleration makes the problem appear and disappear. TB is offering v 102.3.3, but I am not sure that is what you'd like to have tried.

If you still need someone to try something, please let me know what version or where to get it to try, and what you'd like me to report.

Regards

icnivad909:

A 32-bit Windows binary is available for download here:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/YLX039-rQkW0k5LL71GGyg/runs/0/artifacts/public/build/target.zip

It's a build based on Thunderbird 102, so it should work with the same profile that you currently use with your regular Thunderbird 102.x
To be careful, I suggest that you make a backup of your Thunderbird profile folder, prior to trying this build.

To use it, download the zip file, extract it to a temporary folder, and run the thunderbird.exe found in that folder.

Is the bug fixed for you with that experimental thunderbird version?

For others, who are running 64-bit Thunderbird on WIndows, the download link is:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Rder57RrSS--kvq05ebA8w/runs/0/artifacts/public/build/target.zip

Dear Kai, I tried your 32 bit binary. Sadly, the error (empty passwordmanager) is still there.
What I did: I used a PC, where i have never applied the patch (setting layers.acceleration.disabled to true) and a profile from my backup (backup before the passwords dissapeared).

  1. Thunderbird 91: Passwords are there
  2. Upgraded to a recent Thunderbird: Passwords are not visible/ accessible
  3. Tried your build: Just starting the Thunderbird.exe did not work, as my profile was not recognised and Thunderbird asked for setting up a new profile. I replaced the C:\Programs(x86)\Mozilla Thunderbird folder with the folder from your binary and was able to start your version/build with the profile on the NAS. Passwords are not visible in the Passwordmanager and are not recognized by Thunderbird. Setting layers.acceleration.disabled to true still fixes the problem.
    Best regards,
    Axel

Sorry I took so long, I've been heads down on other things. Not it's not safe to back out. We need the actual patch in NSS.

We should figure out why the macs or corrupted on those platforms, if that is indeed what is going one. It almost sounds like there's somthing broken about using HW accelleration on a 32-bit platform. Perhaps the better solution is to turn off hardware acceleration for 32bits. The code that turns that all on is in nss/lib/freebl/blinit.c. We can either disable it all in CheckX86CPUSupport() if we are using 32 bit, or we can figure out what is failing by turning them off one by one with the environment variable and just disabling the particular failing function:
char *disable_hw_aes = PR_GetEnvSecure("NSS_DISABLE_HW_AES");
char *disable_pclmul = PR_GetEnvSecure("NSS_DISABLE_PCLMUL");
char *disable_hw_sha = PR_GetEnvSecure("NSS_DISABLE_HW_SHA");
char *disable_avx = PR_GetEnvSecure("NSS_DISABLE_AVX");
char *disable_avx2 = PR_GetEnvSecure("NSS_DISABLE_AVX2");
char *disable_ssse3 = PR_GetEnvSecure("NSS_DISABLE_SSSE3");
char *disable_sse4_1 = PR_GetEnvSecure("NSS_DISABLE_SSE4_1");
char *disable_sse4_2 = PR_GetEnvSecure("NSS_DISABLE_SSE4_2");

I'm guessing NSS_DISABLE_HW_AES would be sufficient, since we are using AES and not AES_GCM in the password code.

Flags: needinfo?(rrelyea)

If the problem is in NSS code, why does it help to set pref layers.acceleration.disabled to false?
Looking at the code that handles layers.acceleration.disabled, the pref controls HW acceleration for displaying, but apparently it doesn't control NSS behavior.

I conclude hardware acceleration for display purposes has an unexpected side effect. Maybe both display and NSS HW acceleration share some CPU resources in unexpected way.

But if there is such a side effect, why do we get that side effect ONLY when also using a network file system?

To everyone affected by this bug, could you please report if you are using Thunderbird 32bit or 64bit?
You can look it up in the menu, help about. It should report 32bit or 64bit after the version number.

In addition:

To all users who are affected by this bug, could you please help us test Bob's theory from comment 66 ?
I'll explain what you need to do.

First, make sure that you reset Thunderbird pref layers.acceleration.disabled to the original value false, to ensure that you are really testing the effect of the following changes.

Next, you need to set an environment variable on your Windows system. If you have never done that before, I found an article that describes where to find the place in system settings that allows you to set an environment variable:
https://www.computerhope.com/issues/ch000549.htm

You will NOT modify the variable that is described in that article, do NOT modify the PATH variable.
We want to do something else.

In the section for the "user variables", click the "New" button.
For the name, enter NSS_DISABLE_HW_AES and the for the value enter 1

Then ensure that you fully quit and restart Thunderbird.
When in doubt, please reboot.

Is the problem gone?

If the problem isn't gone, you could try to set additional environment variables, one variable for each of the names that Bob gave in comment 66, e.g. NSS_DISABLE_PCLMUL and use value 1 for each variable that you add.

(In reply to Kai Engert (:KaiE:) from comment #69)
Hello Kai,
I just tried all enviroment variables. Unfortunately the probleme is still there :(
I've tested it with TB 102.4.2 (64-Bit)
Edition Windows 10 Pro
Version 21H2
Betriebssystembuild 19044.2251
Leistung Windows Feature Experience Pack 120.2212.4180.0
NAS Synology

Running TBird 102.4.2 x64
Ran through the list of environment variables one at a time. That didn't change anything i.e. no prompt for passwords and the password area was empty on TBird. Re-checked HW acceleration in TBird settings under General and on restart was immediately prompted for passwords. This was different than previous toggling of that HW acceleration setting as the passwords previously appeared to only be "hidden". Now they were gone. Had to re-enter them all.

Oh yeah Windows 10 pro 21h2 Synology NAS

Thank you for testing.

It sounds like Bob's theory from comment 66 is NOT the explanation for this bug.
Both comment 70 and comment 71 mention that 64-bit Thunderbird is used, and the environment variables don't help.

If the problem is in NSS code, why does it help to set pref layers.acceleration.disabled to false?
Oh, that's a thunderbird pref, I thought it was an OS perf to turn HW acceleration off.
We could figure if this is NSS or Thunderbird UI by trying a newer version of nss on an older version of thunderbird . For instance try Thunderbird 91 but copy nss from nss 3.83 and see if that works.

If it is thunderbird, it might be an issue with the password callback. It might be expecting a window context, which could be NULL in some cases.

bob

Using a Synology DS218Play and Windows 11 Pro, I cannot reproduce the bug.

I've configured and mapped a network drive, then I installed Thunderbird 91.13.1, started it with -P, create a fresh profile (selecting a folder on the network drive for new profile location).
I've connected an IMAP account and remembered the password.
Then I upgraded to Thunderbird 102.5.1, and the password was still remembered.
I connected an additional IMAP account, also allowed TB to remember the password.
Restarted TB, and passwords for both accounts were still there.

Initially the Synology had a DSM software from 1 year ago installed.
I've upgraded to the latest DSM software, but that didn't change the behavior, it still works.

Apparently reproducing the NAS isn't as simple as using a NAS, there must be additional factors that cause the bug to occur.

I just realized I did this without having master/primary password.
I'll try that as an additional test.

I repeated the tests with primary password configured.
When prompted, I entered the password at Thunderbird startup.
Remembered passwords still work for me.

Hardware acceleration is enabled in my TB settings.

Axel, comment 4 suggests that the primary password wasn't entered in that test. Of course the passwords cannot be accessed if you have the primary password set and you don't provide it to Thunderbird.

I hope everyone testing this bug always enters the primary password when prompted.

(In reply to Robert Relyea from comment #74)

If it is thunderbird, it might be an issue with the password callback. It might be expecting a window context, which could be NULL in some cases.

Hmm. Axel, if your comment 4 referred to a test in which the user did NOT cancel any primary password prompt, but nevertheless the log produced errors like "NS_ERROR_ABORT: User canceled primary password entry 4 crypto-SDR.js", then Bob's theory could be right.

(In reply to Kai Engert (:KaiE:) from comment #78)

(In reply to Robert Relyea from comment #74)

If it is thunderbird, it might be an issue with the password callback. It might be expecting a window context, which could be NULL in some cases.

Hmm. Axel, if your comment 4 referred to a test in which the user did NOT cancel any primary password prompt, but nevertheless the log produced errors like "NS_ERROR_ABORT: User canceled primary password entry 4 crypto-SDR.js", then Bob's theory could be right.

Dear Kai, we do not use primary passwords for our users.

(In reply to Axel Lang from comment #5)

I just did some more tests: If a mapped drive in the same domain (mapped with the same user as in the OS) is used, we do not have this problem. The problem only occurs, when we use a share of our NAS (mapped with different user credentials: A user/password from another domain) for the storage of the profile. As said before, we were using this setup since years without problems.

Sounds like I should try to find a network drive that's hosted elsewhere (not at home).

I found a cloud storage provider that offers Samba access.
That storage is very slow in comparison to my local network NAS.

I repeated the tests with that slow remote storage.
Still cannot reproduce any failure.

Axel:

Could you please send me the text shown on the "help (menu) / troubleshooting information" page?
Feel free to send by email to kaie@kuix.de
I would like to check if there is something unusual in your configuration.

Flags: needinfo?(axel)

Dear Kai,
I send you an e-mail with the information requested.

Flags: needinfo?(axel)

Hello Kai,
just send you an email (in German) with my "Informationen zur Fehlerbehebung"

Hi all,
I've just updated my Synology from DSM 6 to 7 (7.1.1-42962 Update 3)
Now I can switch on HW-Acceleration without having any problems :)
Tested with TB 102.6.1 and 102.7.1
So the bug seems to affect only Synology Systems with DSM 6
Can anybody else confirm?

Running Synology DS218play DSM 7.1.1.-42962 u2, DS214 6.2.4-25556 u6 windows 11 x64 thunderbird 102.6.1
Problem occurred with profile on DSM 6x NAS after 9x to 10x Tbird upgrade. Turning off HW acceleration "fixed" it.

Use a \server\share\profile approach for profile designation

I copied the profile to the DSM 7x and with HW acceleration ON, the problem was gone.
Accessed the profile on the older 6x NAS and the problem persisted with HW acceleration ON (password prompts, no "saved password").

Did notice this in DSM 7x release notes

DSM 7.0 by default disables NTLMv1 and enables NTMLv2 only, so SMB clients (e.g., Windows XP devices, media players, network printers, smart TVs, and IP cameras) won’t be able to access your Synology NAS. To restore the connection after the update, go to Control Panel > File Services > SMB > Advanced Settings > Others and enable NTLMv1 authentication.

(In reply to perinipm@gmail.com from comment #85)

DSM 7.0 by default disables NTLMv1 and enables NTMLv2 only, so SMB clients (e.g., Windows XP devices, media players, network printers, smart TVs, and IP cameras) won’t be able to access your Synology NAS. To restore the connection after the update, go to Control Panel > File Services > SMB > Advanced Settings > Others and enable NTLMv1 authentication.

Hi perinipm,
I tried with enabling NTLMv1.
-> TB is still working fine with HW-Acceleration
So I think that feature/setting isn't causing the problem.
-> Must be something different in TB-communication to Synology NAS with DSM 6

Typically I use UNC for profile naming convention e.g. \server\share\directory\subdirectery\profile
Tried mapping the profile more directly by creating a share on the NAS \server\share\directory\subdirectory and mapped to O:
reference O:\profile
That actually worked

I had also tried the NTLMv1 but as you said it had no effect. Synology made some meaningful changes on SMB. Considering the lack insight into MS's restricted code and the origin of SMB and LM, it would take some effort to parse out how hardware acceleration is having this effect.

Something to keep an eye on, but otherwise there are workarounds

And I might add that not only does HW enabled work now but with the more direct mapping Thunderbird opens much more quickly

More testing revealed that UNC was not the problem. Synology's DSM 6x seems to be the culprit. Once both pre-10x profile and newer 10x profile were moved to a newer NAS running the 7x DSM version, HW acceleration could be enabled and the password problems disappeared.

If an upgrade to a newer Synology OS fixes the problem, it seems likely that an earlier OS version misbehaved for legitimate file system operations, and that bug has been fixed.

Marking worksforme.
If we really need to analyze what's going wrong, someone could ship a broken device to me ;-)

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
Whiteboard: [fixed by newer Synology OS, DSM 7]
You need to log in before you can comment on or make changes to this bug.