After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 679861 - libsecret migration
libsecret migration
Status: RESOLVED FIXED
Product: gnome-disk-utility
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-disk-utility-maint
gnome-disk-utility-maint
Depends on:
Blocks: 679854 679893
 
 
Reported: 2012-07-13 14:11 UTC by Stef Walter
Modified: 2012-07-27 08:03 UTC
See Also:
GNOME target: 3.6
GNOME version: ---


Attachments
WIP patch to migrate to libsecret (10.56 KB, patch)
2012-07-14 04:18 UTC, Stef Walter
none Details | Review

Description Stef Walter 2012-07-13 14:11:51 UTC
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 gnome-disk-utility: 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 gvfs (See bug #679854)
   used the same schema name when dealing with the same passwords:
     org.gnome.GVfs.Luks.Password
 * I haven't built tested the patch due to missing dependencies.
Comment 1 David Zeuthen (not reading bugmail) 2012-07-13 19:02:00 UTC
Sounds good to me - did you forget to attach the patch or is it something you are currently working on? Thanks!
Comment 2 Olav Vitters 2012-07-13 20:41:31 UTC
Per r-t: Targetting GNOME 3.6
Comment 3 Stef Walter 2012-07-14 04:18:03 UTC
Created attachment 218788 [details] [review]
WIP patch to migrate to libsecret

Whoops, I did indeed forget to attach the patch. Here you go.
Comment 4 Stef Walter 2012-07-14 11:19:37 UTC
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 5 David Zeuthen (not reading bugmail) 2012-07-26 20:32:14 UTC
(In reply to comment #3)
> Created an attachment (id=218788) [details] [review]
> WIP patch to migrate to libsecret
> 
> Whoops, I did indeed forget to attach the patch. Here you go.

I think this is the wrong patch (against empathy it looks like). Anyway, the port was so easy that I just did it based on that patch:

 http://git.gnome.org/browse/gnome-disk-utility/commit/?id=3ddf1ab497d5e67b65822be6941f7cf3d9b2e100
Comment 6 Stef Walter 2012-07-27 08:03:53 UTC
For bonus points use secret_password_free() to clear memory when freeing a password. It supports normal malocc'd and 'special' non-pageable memory.

For even more points (since these are disk encryption passphrases, and you really don't want them to be paged out) use non-pageable memory. You can use something like GcrSecureEntryBuffer on your text entry, and secret_password_lookup_nonpageable_finish() to accomplish that.