Am Dienstag 13 September 2011, um 07:33:31 schrieb Milan Crha:
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
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.
Hum, is ECredentials something a backend can actively request? With NSS, we
need to register an NSS callback function in our backend, which is called by
NSS when NSS tries to open the token for the first time in the session. Since
the token PIN should not be stored anywhere (and removed from memory once the
token is opened), the callback function will be the one triggering a user
dialog to be opened, the PIN entered, passed to the callback function and set
in NSS. After that, the whole dialog stuff will be closed and gone. At least,
that would be the right way of doing it. It's not a hard requirement for us
now (politics have changed a little), but there may be similar requirements
coming from other backends, so I thought of bringing this issue up. And if we
get the functionality for little money, we can make use of it.
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.
Oops, sorry -- I missed to clarify this better. The LDAP access (for
addresses) I was talking about is the one implemented in Evo itself, not the
backend variant. There, we hit the aforementioned problem.
Maybe the new OpenLDAP with NSS support will enable us to do what we need,
since Evo already provides infrastructure for requesting security PINs. Thanks
for the hint!
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48
Description: This is a digitally signed message part.
evolution-hackers mailing list
To change your list options or unsubscribe, visit ...