On Mon, 2011-09-12 at 13:16 +0200, Christian Hilberg wrote: > We succeeded doing so for the following protocols: HTTPS, IMAPS, SMTPS. > These are protocols handled by Camel and the underlying NSS library. In order > to access the crypto token, we needed to supply a token PIN, which we were > not > able to pass from Evo to E-D-S in version 2.30 as "live" data (pass-and- > forget). So we had to use a fake implementation: we store the user PIN along > the rest of the account data and reading it in the backend via ESource. > Clearly, this violates security (and we are saying to in our user manual), > but > it demonstrates that in principle, things are working. To get this thing > right, we would need a means to ask for a security pin from within the > backend, presenting a dialog to the user
Hi, with the current eds (upcoming 3.2.0) you can pass parameters via ECredentials, same as you do with e_passwords_ask_password, thus yes, this is doable from book/cal backends now too. > However, there is one protocol, for which we failed to implement any > demonstrator for client-certificate-based authentication using a hardware > crypto device: LDAPS. The implementation in Evo uses the OpenLDAP lib as a > protocol implementation, which in turn uses GnuTLS for security (version 2.1x > < 2.12 at that time). The OpenLDAP 2.12 is kinda old. And if I recall correctly, they moved to NSS as well, at least 2.4.23 seems to use NSS based on their changelog. Thus, I would say, when you move to current eds, then you can be pretty sure that the used OpenLDAP will be the one with NSS. Or you can add a dependency to evolution-kolab on the OpenLDAP which fits you best. Bye, Milan _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers