Closed Bug 546027 Opened 15 years ago Closed 3 years ago

Kerberos/GSSAPI login to SMTP and POP3 freezes UI on network requests

Categories

(MailNews Core :: Networking: SMTP, defect)

1.9.1 Branch
x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: BenB, Unassigned)

References

Details

Our POP3 and SMTP implementations run on the UI thread. They make their network calls via async necko calls, so they don't block the UI on network. With (at least) one exception: Kerberos ticket gathering is a network operation and happens in the gssapi OS lib, and we call that in GetNextToken(), and we block on that. In other words, while we try to acquire a Kerberos ticket from the KDC which is valid the POP3 or SMTP server, we freeze the UI on that network request. Apparently, nobody noticed, because it was fast enough, but the problem is there (as far as I can see from the code). This problem is aggrevated by bug 524698, which waits for a OS password dialog, during which Thunderbird UI freezes. IMAP does not have this problem, because it's running in a thread.
This is a problem in the API of the auth module (mozilla/extensions/auth/), function GetNextToken(), maybe even in the gssapi lib API. It needs to offer an async API, too (and Mailnews then needs to use that).
yeah i was notice this too. delay is much bigger on dual ip stack, becaus of more dns queries
We're not going to be able to make GSSAPI itself async - there's far too many abstraction layers between us, and what happens on the network. With Kerberos (and we have the guarantee that Kerberos is the only GSSAPI mechanism which can be used under the GSSAPI SASL name) only the first call to gss_init_sec_context will cause network activity - everything else occurs locally. That call will only hit the network if the user already has a Kerberos credentials cache. So, to fix this, we need to move that call out into its own thread, and notify when it completes. The thread safety guarantees in GSSAPI basically mean that a context may be used in multiple threads, providing it is never simultaneously accessed - so this should be doable with some coding.
> we need to move that call out into its own thread Yup, and then we need to adapt the Necko API nsIAuthModule.getNextToken() and its callers :(
This actually apply to LDAP binding too. But from what I understand LDAP having different codebase, so probably better to file new bug.
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Kaie, any hope for this in these more modern times?

Flags: needinfo?(kaie)

Ben, is this still an issue 9 years later?

Flags: needinfo?(kaie) → needinfo?(ben.bucksch)

Hi Kai, I don't use Kerberos since about 10 years. So, I cannot test.
However, I don't think the relevant code changed, so I presume the issue still exists.

Flags: needinfo?(ben.bucksch)

Version 91 has all new smtp backend code. If you can still reproduce this issue, please file a new bug report https://bugzilla.mozilla.org/enter_bug.cgi?product=MailNews%20Core&component=Networking%3A%20SMTP

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.