1:51 a.m.
> For that the command line needs to support GNOME keyring first,
which it
> currently doesn't (#3604). So the current status is:
> * if the user changes the password on the sync-ui, save in GNOME
> keyring with "-" as password in config.in => command line
will
> ask for password, breaking Genesis
> * if the password is stored in config.ini, don't touch it in
> sync-ui
>
> I'm not 100% sure, but I think the second point is the fix that I was
> looking. Jussi, do you know why the password is not shown in the second
> case?
I'm working on bug#3604. I think it will be ready in the next few days.
Cheers,
Yongsheng
-----Original Message-----
From: syncevolution-bounces(a)syncevolution.org
[mailto:syncevolution-bounces@syncevolution.org] On Behalf Of Patrick Ohly
Sent: Thursday, August 27, 2009 10:36 PM
To: Jussi Kukkonen
Cc: syncevolution(a)syncevolution.org
Subject: Re: [SyncEvolution] sync-ui and Genesis compatibility
On Thu, 2009-08-27 at 13:26 +0100, Jussi Kukkonen wrote:
> Patrick Ohly wrote:
> > On Sun, 2009-08-16 at 13:16 +0100, Frederik Elwert wrote:
> >> Am Sonntag, den 16.08.2009, 11:06 +0200 schrieb Patrick Ohly:
> >>> On Sat, 2009-08-15 at 18:34 +0100, Frederik Elwert wrote:
> >> This is of course way better in means of security. Maybe I should have a
> >> look if I can implement this for Genesis as well (if gnome-keyring is
> >> present, I’d like not to depend on GNOME too much). But at least for
> >> Genesis some kind of migration would be necessary: If a password is
> >> present in the config file, delete it there and set it in the GNOME
> >> keyring.
> >
> For that the command line needs to support GNOME keyring first,
which it
> currently doesn't (#3604). So the current status is:
> * if the user changes the password on the sync-ui, save in GNOME
> keyring with "-" as password in config.in => command line
will
> ask for password, breaking Genesis
> * if the password is stored in config.ini, don't touch it in
> sync-ui
>
> I'm not 100% sure, but I think the second point is the fix that I was
> looking. Jussi, do you know why the password is not shown in the second
> case?
>
> Password is not currently transmitted via D-Bus... It probably should be
> at least when we update the config api. Nothing gets broken though: If
> you do set a password with the ui, keyring will be used but otherwise
> the password won't be touched.
I agree, we should transmit the password as part of the revised D-Bus
API. Then we can show that a password is set, which would avoid the
issue that Frederik saw (password seems to be empty). Also, clients with
no support for the keyring can set the password in the config.ini.
>> I don’t have any experience with gnome-keyring, so I’ll have
to see how
>> much work this would be. Is it even possible to access passwords across
>> applications (like Genesis and sync-ui)? How does syncevolution know
>> about the password then? Does it look for it in gnome-keyring for
>> itself, or do I have to pass it to syncevolution somehow?
>
> It is looked up with a set of properties as key:
> http://bugzilla.moblin.org/show_bug.cgi?id=2430#c13
>
> Any application with access to the keyring can read and write it.
The secrets do have individual access permissions. Applications can
grant access rights to the secret: so the UI adds the
syncevo-dbus-server binary into the ACL. If it didn't, there would be a
dialog asking the user to approve the access.
This syncevo-dbus-server => GNOME keyring dependency is problematic for
another reason. Suppose that SyncEvolution is used with a KDE GUI and
Akonadi backends. The GNOME keyring shouldn't be used in such a setup.
I don't know what the KDE equivalent of the GNOME keyring is, and we
shouldn't have to know. This implies that password storage should be
entirely handled by clients, with plain passwords in the config.ini as
fallback.
The drawback is that we have to transmit plain passwords over D-Bus,
something that we wanted to avoid originally.
This is a bit problematic as a generic UI can't really tell where
the
server binary is... My original instinct was that it's not worth it to
add something like this to the API, but the dbus-glib bindings could
have a helper function for adding the server binary to ACL.
Not having the syncevo-dbus-server access the GNOME keyring would avoid
this problem. It would still be a problem if Genesis and sync-ui want to
share access to GNOME keyring, but this could be handled via the access
dialog.
>>>> This surely is not top priority, but I think it
would be nice if one
>>>> could run sync-ui and Genesis next to each other. So services set up
in
>>>> Genesis should work in sync-ui and the other way around. So could
anyone
>>>> help me find out why sync-ui doesn’t recognise the services I set up
>>>> with Genesis? Then I could adjust Genesis’ configuration mechanisms to
>>>> be compatible with sync-ui.
>>> You could use the same gconf key to select the active configuration.
>>> Then sync-ui should work right away. Have a look at
>>> /apps/sync-ui/server in gconf-editor.
>> Ah, that sounds good! It makes sense to store common configuration
>> options in a common place.
So... should this actually be part of syncevolution config?
Yes. We currently don't have any server-independent config, but adding
some key/value pairs which are stored in
~/.config/syncevolution/config.ini wouldn't be hard.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
SyncEvolution(a)syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution