Re: [Evolution-hackers] Further thoughts on ESources

[Matthew Barnes <mbarnes redhat com>]

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.