Bug 52051 - libsecret migration
libsecret migration
Status: RESOLVED DUPLICATE of bug 32578
Product: Telepathy
Classification: Unclassified
Component: mission-control
unspecified
Other All
: medium normal
Assigned To: Telepathy bugs list
Telepathy bugs list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-13 13:12 UTC by Stef Walter
Modified: 2013-08-29 14:07 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
WIP patch to migrate to libsecret (8.32 KB, patch)
2012-07-13 13:12 UTC, Stef Walter
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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 ***