Re: [Evolution-hackers] Further thoughts on ESources

2011-09-12 Thread Christian Hilberg
Hi all,

Am Donnerstag 25 August 2011, um 18:46:15 schrieb Matthew Barnes:
 [...] 
 Proposal:
 
 I think the key file management needs to be centralized in a new D-Bus
 service, tentatively called e-source-registry.  The ESourceRegistry
 singleton class in client programs would then be a proxy for the D-Bus
 service.  So we'd have a bit of a D-Bus hierarchy:
 
 
evolution and other e-d-s clients
 
 e-addressbook-factory   |   e-calendar-factory
   \ | /
 e-source-registry

Are there plans for any sort of live service implemented by this (or yet 
another component), so that e.g. a backend implementation can query for user 
input when it needs it?
  The use case I have in mind originates from the problem we are facing in 
evolution-kolab backend processes, that we cannot ask for a security PIN 
(which should not be stored anywhere, but be used-and-forgotten) when opening 
a security hardware device for a session. If you see Evolution as any one of 
possibly multiple clients to E-D-S, then it probably makes no sense to pop-up 
any *Evo* dialogue to ask for the PIN. This would make Evo an even more 
privileged E-D-S client than it currently is, while my understanding of the 
current development seems to be to rid Evo of it's privileged status and turn 
it more into a yet-another E-D-S client.
  For the problem at hand, we would most probably need some dumb input dialog 
to pop up, requesting the token PIN, and be gone again - the way security 
tokens should be used mandates their PIN not be stored *anywhere*, not even in 
a gnome-keyring or services like that... so I'm curious which plans may exist 
here (or may need thought-smithing ;-).

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] Further thoughts on ESources

2011-09-12 Thread Matthew Barnes
On Mon, 2011-09-12 at 13:30 +0200, Christian Hilberg wrote: 
 Am Donnerstag 25 August 2011, um 18:46:15 schrieb Matthew Barnes:
  
 evolution and other e-d-s clients
  
  e-addressbook-factory   |   e-calendar-factory
\ | /
  e-source-registry
 
 Are there plans for any sort of live service implemented by this (or yet 
 another component), so that e.g. a backend implementation can query for user 
 input when it needs it?

Yes, in fact the more I think about the problem the more I'm convinced
that this new low-level D-Bus service should handle user authentication
prompts in a manner similar to PolicyKit user prompts.  (In other words,
PolicyKit handles user prompts itself and doesn't force each and every
PolicyKit client to deal with it -- so we can mimic its solution for
address book and calendar authentication.)


 The use case I have in mind originates from the problem we are facing in 
 evolution-kolab backend processes, that we cannot ask for a security PIN 
 (which should not be stored anywhere, but be used-and-forgotten) when opening 
 a security hardware device for a session. If you see Evolution as any one of 
 possibly multiple clients to E-D-S, then it probably makes no sense to pop-up 
 any *Evo* dialogue to ask for the PIN. This would make Evo an even more 
 privileged E-D-S client than it currently is, while my understanding of the 
 current development seems to be to rid Evo of it's privileged status and turn 
 it more into a yet-another E-D-S client.
   For the problem at hand, we would most probably need some dumb input dialog 
 to pop up, requesting the token PIN, and be gone again - the way security 
 tokens should be used mandates their PIN not be stored *anywhere*, not even 
 in 
 a gnome-keyring or services like that... so I'm curious which plans may exist 
 here (or may need thought-smithing ;-).

I mentioned earlier that with E-D-S moving to EExtension, the D-Bus
services can now be extended for purposes other than simply registering
new backend types.  Perhaps this is a use case.

I'm woefully ignorant about most security APIs and the issues they try
to address.  I can help with the nuts and bolts details, but for more
conceptual questions (such as those raised in your security post), I'd
recommend consulting with and possibly bringing into the discussion Stef
Walter -- the gnome-keyring author -- who is more aware of the state of
NSS vs. Gnutls and has been helping to add security support to GNOME
libraries.  He might even have a ready-made solution to your token issue
in one of his libraries.


___
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] Further thoughts on ESources

2011-08-25 Thread Matthew Barnes
Now that my head's back into account management issues, I wanted to
brain storm about something that's been knocking around in my brain for
a few weeks.  Seeing how David Zeuthen implemented the Online Accounts
service I think has influenced my thinking.

Right now on the account-mgmt branch I've got this ESourceRegistry
singleton class which collects all the ESource objects in one place and
monitors the corresponding key files and the directory they live in for
changes.

http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/ESourceRegistry.html

However, every process -- be it the addressbook/calendar factories,
Evolution or any other client -- will need its own ESourceRegistry
instance and hence would be doing its own file monitoring.  The idea is
through file monitors all the processes are supposed keep their ESources
in-sync.

I think that approach would probably work in practice -- since ESource
contents will rarely change.  But it feels increasingly wrong to me from
an architectural viewpoint.

Consider this: the GNOME Online Accounts integration module I wrote
recently lives in Evolution, which is clearly the wrong place for it,
but we don't currently have a place for it in Evolution-Data-Server.
That means if you set up a Google account through Control Center, your
Google Calendar appointments will not show up in GNOME Shell calendar
until you start Evolution so that the online-accounts module can set
up ESources for you.

Proposal:

I think the key file management needs to be centralized in a new D-Bus
service, tentatively called e-source-registry.  The ESourceRegistry
singleton class in client programs would then be a proxy for the D-Bus
service.  So we'd have a bit of a D-Bus hierarchy:


   evolution and other e-d-s clients
 |  |  |
e-addressbook-factory   |   e-calendar-factory
  \ | /
e-source-registry


The e-source-registry process would be extensible of course, with its
own set of dynamically loaded modules.

That would give the online-accounts module a more natural place to
live, and would help strip Evolution of its special E-D-S privileges,
making it closer to being just another E-D-S client, which I think has
always been the intent.

Moreover, it would give groupware extensions (Exchange, etc.) a place to
install modules that can monitor an account and keep local ESources in
sync with remote resources.  For example if a new calendar shows up on
an Exchange server (perhaps from the user doing stuff through the web),
the Exchange e-source-registry module could notice the change and define
a new ESource for that calendar.  All without ever starting Evolution.

I haven't worked out all the logistics or a D-Bus API yet, so this is
still a bit hand wavy.  But the new GDBus code generation tools in GLib
2.30 should make this fairly easy to set up.  It was for David when he
wrote GNOME Online Accounts.  And it feels like the right direction.

Once I get the branch building again, I think I'll spend a little time
playing with this idea and see if it pans out.

Comments?

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] Further thoughts on ESources

2011-08-25 Thread Milan Crha
On Thu, 2011-08-25 at 12:46 -0400, Matthew Barnes wrote:
 Proposal:
 
 I think the key file management needs to be centralized in a new D-Bus
 service, tentatively called e-source-registry.  The ESourceRegistry
 singleton class in client programs would then be a proxy for the D-Bus
 service.  So we'd have a bit of a D-Bus hierarchy:
 
 
evolution and other e-d-s clients
  |  |  |
 e-addressbook-factory   |   e-calendar-factory
   \ | /
 e-source-registry
 
 
 The e-source-registry process would be extensible of course, with its
 own set of dynamically loaded modules.

Hi,
sounds good. One thing for a process name, it would be better to call it
evolution-source-registry, because Chen mentioned similar for factories
as well, but we never took a consensus on it and thus their name was
never changed.

 I haven't worked out all the logistics or a D-Bus API yet, so this is
 still a bit hand wavy.

One question comes on my mind: what will consumers do if the registry
process crashes? As long as you want to make it extensible, and the
example of exchange extension of doing stuff on a server, then it can
sometime result in a crash for sure. And seeing a flood panic on all
consumers might be sort of fun.

 But the new GDBus code generation tools in GLib
 2.30 should make this fairly easy to set up.  It was for David when he
 wrote GNOME Online Accounts.  And it feels like the right direction.

Pity I didn't notice existence of the GDBus code generation tool before
I wrote all the templates for GDBus calls by hand. Though with all those
macros it seems to me like easier to read, if anyone would ever like to
read it. ;)
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