Re: [Evolution-hackers] Evo/E-D-S security (libs) long-term plans

[Milan Crha <mcrha redhat com>]

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