392016 - User certificates are not retrieved if Address Autocompletion for LDAP is (globally) disabled

Status: RESOLVED FIXED

(Thunderbird :: Security, defect, P2)

Description

[Jan Peter Stotz]

User-Agent:       Opera/9.22 (Windows NT 5.1; U; de)
Build Identifier: Version 2.0.0.6 (20070728)

As Thunderbird allows to specify for each mail account a different LDAP server (Account Settings -> Composition and Addressing -> "Use a different LDAP server") there is no need to set a global Directory Server in the options dialog (Options -> Composition -> Addressing -> Address Autocompletion).

The problem is , that if you do not set a "Directory Server" in the Options dialog, user certificate retrieval does not work. I sniffed the LDAP connection and Thunderbird did never tried to retrieve a user certificate if "Directory Server" is disabled/not LDAP server is specified. But if you enable it user certificate retrieval does work as expected.



Reproducible: Always

Steps to Reproduce:
1. Add a working LDAP server to the Adressbook of Thunderbird
2. Go to Options -> Composition -> Adressing -> Address Autocompletion
3. Make sure "Directory Server" is disabled
4. Open the "Account Settings" and select the "Composition and Addressing" tab for one mail account
5. Choose the in 1. entered LDAP server as "Use a different LDAP server"
6. Accept the settings and close the dialog
7. Compose a new S/MIME encrypted mail and add a email address to the "to field" which certificate is unknown to Thunderbird but is available if the LDAP server and try to save it
Actual Results:  
An error dialog appears saying that the certificate could not be retrieved

Expected Results:  
The correspondant certificate should be loaded from the LDAP server.

If in step 3. the "Directory Server" is enabled the certificate is retrieved - independent of the selected LDAP server in this dialog (works even if "None" is selected)

Comment 2

[Mark Banner (:standard8)]

There's an error in the javascript, it uses the global preference to see if autocomplete is enabled in both cases. This is definitely wrong and easy to fix. Putting on my TB 3 radar.

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/mail/extensions/smime/content/msgCompSMIMEOverlay.js&rev=1.4&mark=383-405#383

Comment 3

[Mark Banner (:standard8)]

Attachment: Thunderbird fix

This should correctly get the right ldap server based on the identity - basically check the identity first, and then revert to the global preference if necessary.

I've not tested this as I haven't got the required set-up, but I believe it should work fine.

Comment 4

[Mark Banner (:standard8)]

Attachment: SeaMonkey fix

Comment 5

[[e-mail]]

Comment on attachment 326867 [details] [diff] [review]
SeaMonkey fix

>+    if (gCurrentIdentity.overrideGlobalPref)
>+      autocompleteDirectory = gCurrentIdentity.directoryServer;
>+
>+    // Don't use an else here, just in case autocompleteDirectory is ""
>+    if (!autocompleteDirectory)
Actually I think the else here is correct. r+sr=me with that fixed.

Comment 6

[Mark Banner (:standard8)]

Attachment: [checked in] SeaMonkey fix v2

The SeaMonkey fix that I'm checking in.

Comment 7

[Mark Banner (:standard8)]

Attachment: [checked in] Thunderbird fix v2

Revised to include the else (so that we match the algorithm in MsgComposeCommands.js)