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 679866 - drop SoupPasswordManagerGNOME
drop SoupPasswordManagerGNOME
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: Misc
unspecified
Other Linux
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks: 679893
 
 
Reported: 2012-07-13 14:58 UTC by Stef Walter
Modified: 2012-12-11 15:23 UTC
See Also:
GNOME target: 3.8
GNOME version: ---


Attachments
WIP patch to migrate to libsecret (10.84 KB, patch)
2012-07-13 14:58 UTC, Stef Walter
rejected Details | Review

Description Stef Walter 2012-07-13 14:58:04 UTC
Created attachment 218732 [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 libsoup: it
solves threading issues, uses GDBus instead of dbus-glib, better support for cancellation.

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:

 * Ideally libsoup would use its own password schema, and not use 
   SECRET_SCHEMA_COMPAT_NETWORK (which is the successor of
   gnome_keyring_set_network_password() and friends). By using its own
   password schema seahorse and other applications can better identify
   the passwords that libsoup stores. But of course changing isn't so simple
   as it would break for already stored passwords.
 * I haven't tested the patch. I'm not familiar with how to trigger all the
   various code paths and logic.

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 libsoup for any API changes that come up.
Comment 1 Dan Winship 2012-07-13 15:18:30 UTC
see also bug 594377; I'm hoping the fix here is going to be that SoupPasswordManager gets deprecated, and so this code would end up going into epiphany (or WebKit?) directly instead.
Comment 2 Stef Walter 2012-07-13 15:42:24 UTC
Makes sense. Hoping to deprecate libgnome-keyring by 3.8 so that gives lots of time for other solutions.
Comment 3 Olav Vitters 2012-07-13 20:42:08 UTC
Per r-t: Targetting GNOME 3.6
Comment 4 Stef Walter 2012-07-14 11:20:02 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 Dan Winship 2012-08-22 17:06:25 UTC
Comment on attachment 218732 [details] [review]
WIP patch to migrate to libsecret

I'll be removing SoupPasswordManagerGNOME entirely, but this patch was useful for migrating this code into epiphany (see new patch on bug 679918)
Comment 6 Matthias Clasen 2012-09-17 19:45:53 UTC
Moving off the 3.6 blocker list
Comment 7 Dan Winship 2012-12-11 15:23:17 UTC
gone!