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

2011-09-13 Thread Christian Hilberg
Hi Milan,

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
  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.

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!

Kind regards,

Christian

-- 
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [evolution-kolab] On porting and extending the plugin

2011-09-13 Thread Christian Hilberg
Hi again,

one more thought:

It would be nice from my developer's point of view if it was possible to do the
UI extensions via some extension mechanism like EExtension, which would speed up
the implementation process for me. However, Matt has a point when he says (in 
[3])
that he does not want Evo to decline into some tacking on of arbitrary 
features kind
of user experience. The question here is whether such an UI extension could 
still
be done as an EExtension or should it rather be implemented in Evo itself.

Kind regards,

Christian


Am Dienstag 13 September 2011, um 15:56:00 schrieb Christian Hilberg:
 [...]
 [3] 
 http://mail.gnome.org/archives/evolution-hackers/2011-September/msg00030.html

-- 
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] SyncEvolution + EClient API + EXDATE regression (Bug #655253)

2011-09-13 Thread Patrick Ohly
On Mo, 2011-09-12 at 09:09 +0200, Patrick Ohly wrote:
 On Mo, 2011-09-12 at 07:56 +0200, Milan Crha wrote:
  On Fri, 2011-09-09 at 10:32 +0200, Patrick Ohly wrote:
   Milan, can you shed some light on why the patch solves #655253? I fail
   to see what e_cal_backend_file_modify_object() has to do with deleting
   one occurrence of a repeatable event.
   
   If the EXDATE was really necessary to avoid having the original and the
   detached recurrence show up, then IMHO adding the EXDATE only works
   around the real problem. The real problem is more likely to be in the
   matching against RECURRENCE-ID.
  
  Hi,
  sure, the thing why I added it there is that when you move one instance
  of a recurring event to another hour, then you are asked whether you
  want to change time for all instances or only this instance. Moving only
  this instance should create a detached instance, and create an exception
  in the master object.
 
 No, creating the exception is not necessary.
 
 Suppose you have a VEVENT with RRULE which expands to a regular start
 time of one recurrence at, say, 20110912T09Z. Then the detached
 recurrence must have RECURRENCE-ID:20110912T09Z and it will
 *replace* the regular recurrence without having to add an EXDATE to the
 parent. That's part of the iCalendar 2.0 semantic.

The root cause of the bug is that the detached recurrences, if created
with current Evolution master, do not get the same UID as the original
recurring event. I've verified that by looking at the resulting .ics
file.

It works correctly in 2.32.4.

Does anyone know where in the 3.x cycle this broke?

-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] SyncEvolution + EClient API + EXDATE regression (Bug #655253)

2011-09-13 Thread Patrick Ohly
On Di, 2011-09-13 at 17:59 +0200, Patrick Ohly wrote:
 On Mo, 2011-09-12 at 09:09 +0200, Patrick Ohly wrote:
  On Mo, 2011-09-12 at 07:56 +0200, Milan Crha wrote:
   On Fri, 2011-09-09 at 10:32 +0200, Patrick Ohly wrote:
Milan, can you shed some light on why the patch solves #655253? I fail
to see what e_cal_backend_file_modify_object() has to do with deleting
one occurrence of a repeatable event.

If the EXDATE was really necessary to avoid having the original and the
detached recurrence show up, then IMHO adding the EXDATE only works
around the real problem. The real problem is more likely to be in the
matching against RECURRENCE-ID.
   
 Hi,
   sure, the thing why I added it there is that when you move one instance
   of a recurring event to another hour, then you are asked whether you
   want to change time for all instances or only this instance. Moving only
   this instance should create a detached instance, and create an exception
   in the master object.
  
  No, creating the exception is not necessary.
  
  Suppose you have a VEVENT with RRULE which expands to a regular start
  time of one recurrence at, say, 20110912T09Z. Then the detached
  recurrence must have RECURRENCE-ID:20110912T09Z and it will
  *replace* the regular recurrence without having to add an EXDATE to the
  parent. That's part of the iCalendar 2.0 semantic.
 
 The root cause of the bug is that the detached recurrences, if created
 with current Evolution master, do not get the same UID as the original
 recurring event. I've verified that by looking at the resulting .ics
 file.
 
 It works correctly in 2.32.4.
 
 Does anyone know where in the 3.x cycle this broke?

Darn, I can no longer reproduce the problem. I was able to reproduce
with the source from current master (thus my statement above about the
UIDs not matching), but after removing the EXDATE code it all works
fine: same UID, no duplicates shown even after restart. Even after
restoring the original source it still works (same UID, EXDATE added).

Milan, do you agree that the e_cal_util_remove_instances() call can and
should be removed? Either way, it only works around whatever is causing
the UID issue. Adding the EXDATE just pampers over that problem and
still doesn't fix things like remove all recurrences.

Patch is here:

diff --git a/calendar/backends/file/e-cal-backend-file.c 
b/calendar/backends/file/e-cal-backend-file.c
index 2dc9a90..e1cfbb3 100644
--- a/calendar/backends/file/e-cal-backend-file.c
+++ b/calendar/backends/file/e-cal-backend-file.c
@@ -2391,9 +2391,6 @@ e_cal_backend_file_modify_object (ECalBackendSync 
*backend,
priv-comp = g_list_remove (priv-comp, recurrence);
obj_data-recurrences_list = g_list_remove 
(obj_data-recurrences_list, recurrence);
g_hash_table_remove (obj_data-recurrences, rid);
-   } else if (obj_data-full_object) {
-   /* add exception for the modified instance */
-   e_cal_util_remove_instances 
(e_cal_component_get_icalcomponent (obj_data-full_object), icalt
}
 
/* add the detached instance */

-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers