Bug 52051

Summary:	libsecret migration
Product:	Telepathy	Reporter:	Stef Walter <stefw>
Component:	mission-control	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED DUPLICATE	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	WIP patch to migrate to libsecret

Description Stef Walter 2012-07-13 13:12:27 UTC

Created attachment 64171 [details] [review]
WIP patch to migrate to libsecret

libsecret is a new client for the Secret Service DBus API. The Secret Service
allows storage of passwords in a common way on the desktop. Supported by
gnome-keyring and ksecretservice.

libsecret solves many problems with libgnome-keyring. Relevant to telepathy: it
solves threading issues, uses GDBus instead of dbus-glib.

A future GNOME goal will be to migrate away from libgnome-keyring to libsecret:

https://live.gnome.org/GnomeGoals/LibsecretMigration

I've done a rough WIP patch in order to make sure that the libsecret API
covered all the use cases. I'll attach that patch here. I hope the patch is a
help for the migration, but I don't plan to iterate on it at the current time.

Some notes about the patch:

 * I chose an arbitrary schema name for the stored items, you may want to
   change it to something better. It would be good if empathy and other 
   code that looks up these passwords uses the the same schema and name.
     org.freedesktop.Telepathy.MissionControl
 * I haven't tested the patch. I'm not familiar with how to trigger all the
   various code paths and logic.
 * secret_password_remove_sync() removes all matching unlocked items as
   opposed the way that gnome_keyring_find_items_sync() +
   gnome_keyring_item_delete_sync() were previously used to unlock all the
   items to delete them. This is a corner case, but if you want the previous
   behavior, you can use secret_service_search() and secret_item_delete() to
   make that happen.
 * I didn't patch any of the tests. If you want a 'mock' Secret Service to
   run tests against, rather than running against a live gnome-keyring-daemon,
   then you can copy this stuff:
   http://git.gnome.org/browse/libsecret/tree/libsecret/tests/mock

Note that the patch uses the unstable 'advanced' parts of the libsecret API.

In particular, it's not "best practice" to use gnome-keyring as a place to
store account or connection details. In an ideal world gnome-keyring would be
used just to store secrets, and attributes are used to lookup those secrets.
However libsecret supports this use case, but that functionality is not yet
absolutely stable.

I'm aiming to get most of this stable by GNOME 3.8, but if you do migrate to
libsecret before then, I would patch telepathy-mission-control for any API changes that come up.

Comment 1 Stef Walter 2012-07-13 13:13:27 UTC

Oh, and it's not a problem for libsecret to read passwords stored by libgnome-keyring and vs. versa, if you use the SECRET_SCHEMA_DONT_MATCH_NAME flag in the schema, which the patch does.

Comment 2 Stef Walter 2012-07-14 11:17:42 UTC

BTW, just a heads up: Please look at the patch critically. I did the patch as a way to try out the API, and it's not ready to commit. There may be memory leaks or other logic errors. Most libsecret getters return data that must be unreferenced or freed.

Comment 3 Guillaume Desmottes 2012-07-16 07:34:53 UTC

Isn't SASL API mandatory now? Maybe now is a good time to remove keyring support from MC?

Comment 4 Simon McVittie 2012-07-17 09:56:25 UTC

(In reply to comment #3)
> Isn't SASL API mandatory now? Maybe now is a good time to remove keyring
> support from MC?

I would prefer to delete keyring support rather than making it use libsecret. That's Bug #32578, blocked by Bug #42088.

To delete keyring support we might still need to link libgnome-keyring for a short time (one GNOME release?), in order to migrate the old passwords from the keyring to new storage, and delete them from their old location. Perhaps *that* can migrate to libsecret (it should be less code, and in a less tricky code path).

Bug #27496, Bug #27981 probably go away (or at least become someone else's problem) once keyring support has gone.

Comment 5 Guillaume Desmottes 2012-07-17 13:02:04 UTC

(In reply to comment #4)
> (In reply to comment #3)
> > Isn't SASL API mandatory now? Maybe now is a good time to remove keyring
> > support from MC?
> 
> I would prefer to delete keyring support rather than making it use libsecret.
> That's Bug #32578, blocked by Bug #42088.

Agreed.

> To delete keyring support we might still need to link libgnome-keyring for a
> short time (one GNOME release?), in order to migrate the old passwords from the
> keyring to new storage, and delete them from their old location. Perhaps *that*
> can migrate to libsecret (it should be less code, and in a less tricky code
> path).

Empathy has migration code since a while so I wouldn't bother tbh.

Comment 6 Matthias Clasen 2013-01-02 04:24:19 UTC

Any update on this ? has keyring support been removed by now ?

Comment 7 Simon McVittie 2013-08-29 14:07:27 UTC

Bug #32578 is the removal of GNOME Keyring support. Build with --disable-gnome-keyring if you want a head start.

I don't think we need to bother with a migration step: Empathy already attempts migration, and no longer supports the Python connection managers that can't do interactive password prompting.

*** This bug has been marked as a duplicate of bug 32578 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.