Open Bug 1779613 Opened 25 days ago Updated 3 days ago

S/MIME slow functions make Thunderbird extremely slow since TB 102 - when suggest/notify about encryption possibilities is enabled

Categories

(MailNews Core :: Security: S/MIME, defect, P3)

Thunderbird 102

Tracking

(thunderbird_esr102+ affected, thunderbird104 affected)

ASSIGNED
105 Branch
Tracking Status
thunderbird_esr102 + affected
thunderbird104 --- affected

People

(Reporter: bjoernv, Assigned: KaiE)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: leave-open, perf, Whiteboard: [workaround: mail.smime.remind_encryption_possible false] ketb-needs-analysis)

Attachments

(2 files)

Attached file thunderbird.log

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

Since the Thunderbird 102 update many mail functions are extremely slow, if the an end-to-end encryption with a personal S/MIME certificate is configured for the mail account.

Steps

  1. Setup an S/MIME "personal certificate for digital signing" and for encryption for the current mail account
  2. Do the following tasks:
  3. Create a new mail
  4. Insert a "To" recipient from Address Book by typing some letters
  5. Delete a "To" recipient with delete key
  6. Open a "Draft" mail in "Drafts" IMAP folder

Run "strace" with the following command to observe the times.

strace --timestamps=ms -p $(pidof thunderbird) -e openat,stat 2>&1 | tee /tmp/thunderbird.log

Actual results:

On my setup (openSUSE Tumbleweed, x86_64, 16 GB RAM, Intel i5 CPU, GNOME desktop on Wayland - KDE on Xorg is similar) I measure the following times:

  1. Setup an S/MIME "personal certificate for digital signing" and for encryption for the currenct mail account: 23 seconds
  2. Create a new mail: 12 seconds
  3. Insert a "To" recipient from Address Book by typing some letters: 20 seconds
  4. Delete a "To" recipient with delete key: 10 seconds
  5. Open a "Draft" mail in "Drafts" IMAP folder: 12 seconds

The strace logs look like this (from Action 6: Open a "Draft" mail in "Drafts" IMAP folder)
19:40:21.777 stat("/home/myuser/.thunderbird/xxxxxxxx.Default User/cert9.db-journal", 0x7ffee04b17e8) = -1 ENOENT (No such file or directory)
19:40:21.777 stat("/home/myuser/.thunderbird/xxxxxxxx.Default User/cert9.db-wal", 0x7ffee04b17b8) = -1 ENOENT (No such file or directory)
[... repeated 964 times ...]
19:40:21.777 stat("/home/myuser/.thunderbird/xxxxxxxx.Default User/cert9.db-journal", 0x7ffee04b17e8) = -1 ENOENT (No such file or directory)
19:40:21.777 stat("/home/myuser/.thunderbird/xxxxxxxx.Default User/cert9.db-wal", 0x7ffee04b17b8) = -1 ENOENT (No such file or directory)
[... repeated 6 times ...]

Expected results:

Such long waiting times did not showed in Thunderbird < 102. Without S/MIME certifications Thunderbird behaves normal.

Component: Mail Window Front End → Security: S/MIME
Keywords: perf
Product: Thunderbird → MailNews Core

The S/MIME lookup is known to be very slow. We now do lookup early to be able to suggest/notify about encryption possibilities.

Blocks: tb102found

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

The S/MIME lookup is known to be very slow. We now do lookup early to be able to suggest/notify about encryption possibilities.

That's bug 1771122? So does that address the performance bottlenecks described here?

Severity: -- → S2
Priority: -- → P3
See Also: → 1771122

It's due to bug 1771122 yes.
Bug 1779838 adds some hidden prefs one can use to avoid it.

An open question is, is the slowness caused by bug 1771122, only?
Or, are there additional reasons why it's slow for you?

It's difficult to analyze this remotely.

Please wait for bug 1779838 to be fixed in a 102.x release. It's not yet clear release will have that fix, but it will be mentioned in bug.

Once you have that release, please use settings, config editor, and set mail.smime.remind_encryption_possible to false.

Then restart Thunderbird and test if that fixes all slowness issues, then please given an update in this bug.
If you don't want to wait that long, I could make an experimental 102.x build available for you, that contains that planned change.

Status: UNCONFIRMED → NEW
Ever confirmed: true

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

Once you have that release, please use settings, config editor, and set mail.smime.remind_encryption_possible to false.

Then restart Thunderbird and test if that fixes all slowness issues, then please given an update in this bug.
I installed TB 102.0.3, set mail.smime.remind_encryption_possible to false and restarted TB.

I also setup my S/MIME identity again.

Unfortunately the slowness is still back. I also see again hundreds of such calls:

[pid 17034] 23:55:40.385 newfstatat(AT_FDCWD, "/home/myuser/.thunderbird/xxxxxxxx.Default User/cert9.db-journal", 0x7ffef65c99c0, 0) = -1 ENOENT (No such file or directory)
[pid 17034] 23:55:40.385 newfstatat(AT_FDCWD, "/home/myuser/.thunderbird/xxxxxxxx.Default User/cert9.db-wal", 0x7ffef65c99c0, 0) = -1 ENOENT (No such file or directory)

Bjoern, you are not explaining what version you are using that gives you the slowness.

It's very important for us to know, to understand if this is fixed by the mentioned other bug, or a different problem.

Flags: needinfo?(bjoernv)

Oh, I notice that you did talk about the version.

I missed it, because you had added the following inside the "quoted part" in comment 5, and as a result, your new comment was rendered as "quotation", too.

You said:

I installed TB 102.0.3, set mail.smime.remind_encryption_possible to false and restarted TB.

The version 102.0.3 does NOT YET support this preference.

Bjoern, the "stat" calls you see are unrelated, they should be quick, and shouldn't affect the slowness.

Bjoern, please read my comment 4 again.

I asked you to re-test this bug at a later time - after bug 1779838 receives a comment saying that a version 102.x has received a fix - this has NOT HAPPENED YET.

I also offer you an experimental build. Would you be interested in obtaining a special experimental build that I could prepare for you, and that you would have to manually install and test? If yes, what platform?

An alternative would be for you to download the "daily/nightly" development version of THunderbird, and ensure you're using it with a SEPARATE TEST PROFILE, you'd have to learn how to use profile manager, to ensure you don't accidentally upgrade your primary work profile (because afterwards you cannot go back to stable 102 with that profile). If you are willing to use Thunderbird Daily with a test profile, you'd have to configure that profile with your email account and your S/MIME setup, too. The Daily/NIghly build of THunderbird already does support the mentioned configuration setting.

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

Bjoern, you are not explaining what version you are using that gives you the slowness.

It's very important for us to know, to understand if this is fixed by the mentioned other bug, or a different problem.

The version information is in the header of this bug report: Thunderbird 102

The slowness problem started immediately after the Thunderbird 102 upgrade on my primary computer.

Flags: needinfo?(bjoernv)

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

Bjoern, the "stat" calls you see are unrelated, they should be quick, and shouldn't affect the slowness.

Maybe, but my "strace" timestamps say, that between the first and the last system call stat("/home/myuser/.thunderbird/xxxxxxxx.Default User/cert9.db-journal", 0x7ffee04b17e8) until the last call I have up to 23 seconds pause time.

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

Bjoern, please read my comment 4 again.

I asked you to re-test this bug at a later time - after bug 1779838 receives a comment saying that a version 102.x has received a fix - this has NOT HAPPENED YET.

I also offer you an experimental build. Would you be interested in obtaining a special experimental build that I could prepare for you, and that you would have to manually install and test? If yes, what platform?

An alternative would be for you to download the "daily/nightly" development version of THunderbird, and ensure you're using it with a SEPARATE TEST PROFILE, you'd have to learn how to use profile manager, to ensure you don't accidentally upgrade your primary work profile (because afterwards you cannot go back to stable 102 with that profile). If you are willing to use Thunderbird Daily with a test profile, you'd have to configure that profile with your email account and your S/MIME setup, too. The Daily/NIghly build of THunderbird already does support the mentioned configuration setting.

Okay, I re-tested the preference mail.smime.remind_encryption_possible with TB nightly (thunderbird-105.0a1.en-US.linux-x86_64.tar.bz2).

mail.smime.remind_encryption_possible=false immediately fixes the slowness problem. mail.smime.remind_encryption_possible=true brings the slowness back.

See Also: → 1779838
Summary: S/MIME functions are extremely slow since TB 102 → S/MIME slow functions make Thunderbird extremely slow since TB 102 - when suggest/notify about encryption possibilities is enabled
Whiteboard: [workaround: mail.smime.remind_encryption_possible false]
Duplicate of this bug: 1782735

Carsten, in my opinion, this bug is also a blocker for Thunderbird 102.x to get into Debian testing.

Most likely, the reason for slowness are the OCSP requests that are automatically performed when verifying potential recipient certificates.

It needs debugging to confirm, and analysis to identify potential ways to improve the performance.

A possible, but unfortunate workaround could be to set the notify pref for S/MIME to false by default.

Regressed by: 1771122
Whiteboard: [workaround: mail.smime.remind_encryption_possible false] → [workaround: mail.smime.remind_encryption_possible false] ketb-needs-analysis

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

Most likely, the reason for slowness are the OCSP requests that are automatically performed when verifying potential recipient certificates.

That seems to be it. I am in a slow WiFi network right now, and all the actions are even slower than before.

It needs debugging to confirm, and analysis to identify potential ways to improve the performance.

Currently, these look-ups seem to block Thunderbird, that means switching to the main window it is frozen too.

A possible, but unfortunate workaround could be to set the notify pref for S/MIME to false by default.

Not blocking the whole Thunderbird and notifying about S/MIME a little later would be nice.

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

A possible, but unfortunate workaround could be to set the notify pref for S/MIME to false by default.

Agreed setting mail.smime.remind_encryption_possible to false is something we need to consider.

But we should check exactly where the slowness comes from.
https://searchfox.org/comm-central/rev/5d9c9acef61fac048616f7d92d00a63d877bbd69/mailnews/extensions/smime/nsMsgComposeSecure.cpp#1103,1136 says to only do local verification.

Assignee: nobody → kaie
Status: NEW → ASSIGNED

Comment on attachment 9288604 [details]
Bug 1779613 - Temporarily disable reminder for possible S/MIME encryption because of extreme slow user experience. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): 1771122
User impact if declined: users of s/mime experience very slow interaction
Testing completed (on c-c, etc.): yes, feedback from users
Risk to taking this patch (and alternatives if risky): low

Attachment #9288604 - Flags: approval-comm-esr102?
Attachment #9288604 - Flags: approval-comm-beta?

Let's disable the pref until we better understand what's happening.

Target Milestone: --- → 105 Branch
Keywords: leave-open

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/cec0482b5e26
Temporarily disable reminder for possible S/MIME encryption because of extreme slow user experience. r=mkmelin

Depends on: 1779838

Comment on attachment 9288604 [details]
Bug 1779613 - Temporarily disable reminder for possible S/MIME encryption because of extreme slow user experience. r=mkmelin

[Triage Comment]
Approved for beta

Attachment #9288604 - Flags: approval-comm-beta? → approval-comm-beta+
You need to log in before you can comment on or make changes to this bug.