Re: [Evolution-hackers] Camel Authentication Changes
Hi Matthew, Am Montag 17 Oktober 2011, um 23:48:01 schrieb Matthew Barnes: On Mon, 2011-10-17 at 15:21 +0200, Christian Hilberg wrote: Fair enough, thanks for clarifying. If that's the current status, then nothing is lost if we keep the implementation as-is for now and try it again later on. Still not sure how this whole security puzzle fits together yet, but this sounds like a piece of it: http://stef.thewalter.net/2011/10/redesigning-seahorse-experience.html Seahorse (or the library stack that Seahorse is built on) is supposedly adding support for NSS certificates by GNOME 3.4. This reads interesting, for sure. That means we should soon be able to plug into Seahorse for certificate management instead of talking to NSS directly some time next year. At least that's my hope. The email (backend) factory which is in the makings for carving out email handling from the Evo frontend would surely need a way to be fed with passwords, be it standard user auth or any more advanced thing like opening a security token with a PIN and reading authentication data (like client certificates) from there. Once configured in seahorse, Evo might not need to do more than presenting a dialogue for the general seahorse (stack) password, and everything is set from there on, since the email factory, and possibly other factories as well, will be granted access to the passwords or other authentication data they need, all handled by a service which is controlled/configured via seahorse. Maybe this is a perspective for solving that whole security puzzle? I highly encourage you to contact Stef about your smart card issue, as he can certainly paint a clearer picture than I can. I will do so. I've seen his posts on gnutls-devel regarding the PKCS#11 stuff, and it really seems things start working out in this area. I'm presently having the issue that OpenLDAP won't use a client certificate, since it builds against GnuTLS, and the security token handling is not transparent there for a lib like OpenLDAP. Instead, the application needs to handle all details by itself. My hope would be that this whole seahorse effort will solve most of the trouble... :) Thanks for the hint and 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
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - Oct 18 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet - Chenthill. ___ 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] [Reminder] Evolution community meeting at #evolution-meet channel - Oct 19 - 3:30 PM UTC
On Tue, 2011-10-18 at 12:30 +0200, Christian Hilberg wrote: Hi Chen, Am Dienstag 18 Oktober 2011, um 12:13:04 schrieb Chenthill: Hi, The meeting goes as follows, [...] You sure the meeting is *today*, not tomorrow (i.e. Wednesday), as usual? Just asking. :-) Oh my bad, not again. Its tomorrow - oct 19 :) Thanks for pointing!! - Chenthill. (Bye)^2, Christian ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Move evolution-alarm-notify to E-D-S?
Here's a crazy idea... What do you guys think about moving evolution-alarm-notify to E-D-S as a simple D-Bus service? It could live in the new services directory: evolution-data-server/services/evolution-alarm-notify/ evolution-alarm-notify is already an autostart program, launched when you start your desktop session, well before you ever launch Evolution. Problem is if it dies for some reason it has to be manually restarted, otherwise you'll miss appointment reminders. My thought was if it also claimed a well-known session bus name then it could easily be activated by evolution-calendar-factory on start up, and (most importantly) RE-activated if the calendar factory detects that the bus name lost its owner. The only real Evo-specific things I see in its source code are calls to some GtkTextView utility functions that live in widgets/misc, but we could easily move those functions to libedataserverui. The evolution module has always seemed an odd place for that thing to live, at least to me. Now that we have an obvious slot for it in the evolution-data-server module, what do you think? Matthew Barnes ___ 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] Move evolution-alarm-notify to E-D-S?
On Tue, Oct 18, 2011 at 10:22 PM, Matthew Barnes mbar...@redhat.com wrote: Here's a crazy idea... What do you guys think about moving evolution-alarm-notify to E-D-S as a simple D-Bus service? It could live in the new services directory: evolution-data-server/services/evolution-alarm-notify/ evolution-alarm-notify is already an autostart program, launched when you start your desktop session, well before you ever launch Evolution. Problem is if it dies for some reason it has to be manually restarted, otherwise you'll miss appointment reminders. My thought was if it also claimed a well-known session bus name then it could easily be activated by evolution-calendar-factory on start up, and (most importantly) RE-activated if the calendar factory detects that the bus name lost its owner. I like the idea. It might also be great, if it can notify across the bus for alarms so that any third party program can listen and operate upon. -Srini ___ 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] Move evolution-alarm-notify to E-D-S?
On 18 October 2011 17:52, Matthew Barnes mbar...@redhat.com wrote: Here's a crazy idea... What do you guys think about moving evolution-alarm-notify to E-D-S as a simple D-Bus service? It could live in the new services directory: evolution-data-server/services/evolution-alarm-notify/ evolution-alarm-notify is already an autostart program, launched when you start your desktop session, well before you ever launch Evolution. Problem is if it dies for some reason it has to be manually restarted, otherwise you'll miss appointment reminders. Personally I'd prefer it if the logic in evolution-alarm-notify was cleaned up into a library (I started this, see https://github.com/rossburton/libealarm, but it needs a lot of work) and then the GNOME Shell handle the notifications itself. Currently the notifications are pretty ugly and don't fit in with GNOME 3 at all, which is a shame. e-a-n should probably remain as an example and for people who want Evolution 3 but not GNOME 3, but ideally won't be used. Ross ___ 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] Camel Authentication Changes
On Sat, 2011-10-15 at 11:18 -0400, Matthew Barnes wrote: Just a heads up that I've changed Camel's authentication API to factor out the password loop that each and every provider currently replicates for themselves. Turns out they all have the same basic logic flow. Hi, I'm currently trying to adapt evo-ews to current git master and this change doesn't make much sense there, at least for me, because on the first look there is used a libsoup for authentications, thus no such auth_loop or any same basic logic. I've a larger patch for the ews under go, which I will finish tomorrow, I only wanted to let you know about this and I hoped that you'll help with this particular thing. Thanks in advance, 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
Re: [Evolution-hackers] Camel Authentication Changes
On Tue, 2011-10-18 at 21:29 +0200, Milan Crha wrote: I'm currently trying to adapt evo-ews to current git master and this change doesn't make much sense there, at least for me, because on the first look there is used a libsoup for authentications, thus no such auth_loop or any same basic logic. I've a larger patch for the ews under go, which I will finish tomorrow, I only wanted to let you know about this and I hoped that you'll help with this particular thing. You might have to implement authenticate() and authenticate_finish() instead of authenticate_sync(). Cache the password that authenticate() gives you, hand it to libsoup when it asks for it, and when libsoup responds with a status code, complete the GSimpleAsyncResult you created in authenticate(). ___ 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] Camel Authentication Changes
On Tue, 2011-10-18 at 15:58 -0400, Matthew Barnes wrote: On Tue, 2011-10-18 at 21:29 +0200, Milan Crha wrote: I'm currently trying to adapt evo-ews to current git master and this change doesn't make much sense there, at least for me, because on the first look there is used a libsoup for authentications, thus no such auth_loop or any same basic logic. I've a larger patch for the ews under go, which I will finish tomorrow, I only wanted to let you know about this and I hoped that you'll help with this particular thing. You might have to implement authenticate() and authenticate_finish() instead of authenticate_sync(). Cache the password that authenticate() gives you, hand it to libsoup when it asks for it, and when libsoup responds with a status code, complete the GSimpleAsyncResult you created in authenticate(). Note that this also needs to cope with the case where the password *becomes* invalid in the middle of an active session. The user should be prompted for a new password (repeatedly until they get it right), and then it should work for *all* of mail/cal/ebook access. And if they hit *cancel* instead of entering a valid password, hopefully it'll stop asking rather than popping up a dialog every few seconds until they change to a VT and run 'killall evolution' :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
