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.
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.
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.
Isn't SASL API mandatory now? Maybe now is a good time to remove keyring support from MC?
(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.
(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.
Any update on this ? has keyring support been removed by now ?
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.