notes and task list
last updated (1-15-2002)
Dan Mosedale and Seth Spitzer
1) first, we need to switch to LDAP SDK v 50 (dmose)
we're currently using LDAP SDK 4.0 (in mozilla/directory/c-sdk)
The reasons we need to update to 5.0 are:
- that 4.0 is the the c-sdk with all the crypto hooks removed. 4.0 came out before the crypto laws changed. we need to plug NSS into the c-sdk.
- 5.0 has support to allow us to plug in NSPR
- NSS requires NSPR
According to dmose, 4.1 would work, but the 5.0 branch is the LDAP SDK "tip", and has some bug fixes that 4.1 doesn't.
According to dmose, there isn't much work going on the 5.0 branch.
Our plan would be do to the work to update to 5.0, land, and once a stable point is achieved, fix the mozilla build scripts to pull the 5.0 branch by date (or by static tag), so that any changes on the 5.0 branch would not break tinderbox or affect us.
Main tasks to switch from 4.0 to 5.0:
1) apply the changes we've made for mozilla on 4.0 branch to the 5.0 branch (including build system changes, like the autoconf changes).
2) get it to build on the big 4 platforms (the ones on tinderbox: mac classic, os x, win32, linux). See Other Tasks for the other platforms.
3) fix the mozilla build scripts to pull the 5.0 branch by date (or static tag)
4) test and make sure LDAP autocomplete, LDAP addressbooks are working (and other exiting features that use the LDAP SDK)
Note, dmose doesn't think there should be any major API changes from LDAP SDK 4.0 to 5.0
2) We need to figure out how LDAP SDK, necko, NSPR, NSS and PSM play together, and how we hook them up. (sspitzer)
For cert selection, security errors we need to pass in PSM functions for the hooks that NSS provides.
1) does PSM require necko? (to do POP over SSL all we had do was this:
from nsPop3Protocol.cpp: if (isSecure) rv = OpenNetworkSocketWithInfo(hostName.get(), port, "ssl-forcehandshake",ir); else rv = OpenNetworkSocketWithInfo(hostName.get(), port, nsnull, ir);
But that is because we use necko. What do we have to do get a secure LDAP connection?
2) Figure out how LDAP SDK, necko, NSPR, NSS and PSM play together
people to start talking to:
Javier Delgadillo (email@example.com)
Stephane Saux (firstname.lastname@example.org, manager)
Brian Ryner (email@example.com, has some PSM background)
Mark Smith (firstname.lastname@example.org, ldap sdk guru)
email@example.com (ldap sdk guru)
3) LDAP connection service (do this last, not assigned yet)
this would associate LDAP connections and LDAP servers with authentication information (username, password) and certificate information.
The reasons for this:
- to avoid having to go to PSM on every secure LDAP connection. if we get certs from PSM, and pass them to NSS, we could keep track of the cert in the LDAP connection cache, so that we wouldn't have to do this more than once per session. (assumption, PSM is expensive)
- if establishing a secure LDAP connection cause PSM to pop up UI, it would prevent this from happening on every secure LDAP connection, as we'd be able
- to keep track of which cert to use for connections to a given server.
- to avoid asking the user for username and / or password on every authenticated LDAP connection. (wait, this would be in wallet, based on ldap:// url, not the LDAP connection service, right?)
- this would allow us to re-use LDAP connections. currently, we create new LDAP connections for every action (every autocomplete, every AB LDAP search, etc.). We could cache and re-use LDAP connections, like we do for IMAP and NNTP connections.
- finish the scheme stuff. We'll need this to make LDIF export / import non-lossy, and to make it so LDAP attributes map better to our addressbook. But it can wait, and doesn't block LDAP over SSL, so we should work on it later.
- once we get the LDAP SDK 5.0 to build on the main tinderbox platforms, finishing the build system work can be handed off. dmose thinks it should be possible to do all platforms at once. But we've agreed, if other platforms are broken, someone else (not dmose) can work on them while dmose continues on with other LDAP over SSL tasks.
- support "blobs". the LDAP SDK allows you to get binary data from the directory server. this is not exposed in the wrapper code around the LDAP SDK. We'll need this for doing secure email w/ autocomplete. (After LDAP autocomplete, we'd then ask the LDAP server "give me the cert (binary data) for the this user, and use it for encrypting this message on send." this can wait.
- LDAP connect is blocking, which causes us to block the UI thread (right, dmose?)
- fix problems (like no alert) when DNS lookup fails on a LDAP server hostname.
- [this is really needed, but in worst case scenario] LDAP Connection
Service. worst case scenario (and this is bad), for LDAP over SSL,
the user is prompted to pick their cert (if the PSM code can't do it automatically)
every time we establishing an LDAP connection. Given that this would
be on every autocomplete, this would be pretty bad.