Not that I know of. Libsecret is a DBus wrapper around the shared secret services provided by environments like GNOME (gnome-keyring) and KDE (Kwallet); this usually implies that you're targeting either of these environments, using their own DBus API (GDBus, for GNOME; QtDBus for KDE). Additionally, the python-dbus bindings used by that Python module use the deprecated dbus-glib API, so I would not recommend using them either. Ciao, Emmanuele. On 5 February 2017 at 15:19, Gábor Csárdi <csardi.gabor+gtk-list@xxxxxxxxx> wrote: > Thanks much! This again saved me a lot of time and effort. OK, so I'll see > what I can do with libdbus then. > > My last question. Do you know if anyone has even written a libsecret client > on top of (lib)dbus only? The secretstorage Python module > (https://github.com/mitya57/secretstorage) seems to do that, but it uses the > Python dbus client, and I'll need to write everything in C. > > Thanks! > Gabor > > On Sun, Feb 5, 2017 at 1:30 PM, Emmanuele Bassi <ebassi@xxxxxxxxx> wrote: >> >> Hi; >> >> On 5 February 2017 at 12:51, Gábor Csárdi >> <csardi.gabor+gtk-list@xxxxxxxxx> wrote: >> > Thanks! R is single threaded and synchronous (focus is computation, not >> > I/O), so I don't need threaded code at all. >> >> Okay; just remember this in case you need to do asynchronous work. >> >> > Btw. I could also just have a dbus client using TCP/IP, right? >> >> No. The support for unauthenticated TCP connections is meant for >> private connections, which means you would not be able to access the >> session bus where the secrets manager lives. >> >> You'd need a special system configuration to allow TCP connections to >> the session bus, but it's *strongly* discouraged to do so, unless you >> want third parties to listen in to everything that gets sent through >> the bus. >> >> Ciao, >> Emmanuele. >> >> > Gabor >> > >> > On Sun, Feb 5, 2017 at 11:36 AM, Emmanuele Bassi <ebassi@xxxxxxxxx> >> > wrote: >> >> >> >> Yes. Libdbus is a fairly low level API and has known limitations for >> >> threaded code. It's the reference implementation of the DBus >> >> specification, >> >> and as such it should only be used if nothing else is available. >> >> >> >> Ciao, >> >> Emmanuele. >> >> >> >> On Sun, 5 Feb 2017 at 10:51, Gábor Csárdi >> >> <csardi.gabor+gtk-list@xxxxxxxxx> wrote: >> >>> >> >>> Thanks much, this saves me from a lot of trouble! >> >>> >> >>> I'll look at libdbus. That's probably a lot more work, I'll need to >> >>> implement a small libsecret client, right? >> >>> >> >>> Thanks, >> >>> Gabor >> >>> >> >>> On Sun, Feb 5, 2017 at 10:36 AM, Emmanuele Bassi <ebassi@xxxxxxxxx> >> >>> wrote: >> >>>> >> >>>> Hi; >> >>>> >> >>>> You cannot ever unload libgobject - and any other gobject based >> >>>> libraries - with dlclose() after dlopen()-ing them. The type system >> >>>> cannot >> >>>> be reset on library unload, and thus types that were registered once >> >>>> will >> >>>> still be alive the next time you load the library. Additionally, GLib >> >>>> and >> >>>> GObject and GIO have threads and additional state created for things >> >>>> like >> >>>> GDBus, which libsecret uses internally to talk to the secrets >> >>>> service. >> >>>> >> >>>> In short: if you want to have a plugin that talks to the password and >> >>>> secret storage through the Secret Service DBus API, you will have to >> >>>> use a >> >>>> library that allows unloading and reloading; likely only libdbus. >> >>>> Alternatively, do not allow disabling the plugin if you want to use >> >>>> libsecret. >> >>>> >> >>>> Ciao, >> >>>> Emmanuele. >> >>>> >> >>>> On Sun, 5 Feb 2017 at 10:27, Gábor Csárdi >> >>>> <csardi.gabor+gtk-list@xxxxxxxxx> wrote: >> >>>>> >> >>>>> Hi all, >> >>>>> >> >>>>> I have a plugin that uses libsecret, and thus glib, on Linux. (It is >> >>>>> a >> >>>>> package for R.) >> >>>>> >> >>>>> It is loaded with dlopen(), and it (ideally) can be unloaded with >> >>>>> dlclose(). I use the synchronous libsecret functions, which AFAICT >> >>>>> run a >> >>>>> temporary glib event loop for each libsecret query. E.g. this is >> >>>>> what I am >> >>>>> doing: >> >>>>> >> >>>>> GError *err = NULL; >> >>>>> >> >>>>> gchar *password = secret_password_lookup_sync ( >> >>>>> keyring_secret_service_schema(), >> >>>>> /* cancellable = */ NULL, >> >>>>> &err, >> >>>>> "service", cservice, >> >>>>> "username", cusername, >> >>>>> NULL); >> >>>>> >> >>>>> if (err) { >> >>>>> if (password) secret_password_free(password); >> >>>>> keyring_secret_service_handle_status("get", TRUE, err); >> >>>>> } >> >>>>> >> >>>>> if (!password) { >> >>>>> error("keyring item not found"); >> >>>>> return R_NilValue; >> >>>>> >> >>>>> } else { >> >>>>> secret_password_free(password); >> >>>>> /* ... */ >> >>>>> return result; >> >>>>> } >> >>>>> >> >>>>> When the lib is unloaded I call secret_service_disconnect(), I >> >>>>> checked >> >>>>> that this is called. I do link to libgobject-2.0, I even call >> >>>>> g_type_ensure >> >>>>> (G_TYPE_OBJECT) to make sure that the constructors in libgobject >> >>>>> run. >> >>>>> >> >>>>> However, it seems that the worker threads for glib (?) are never >> >>>>> cleaned up. Even if I dlclose() the lib, they are there. What am I >> >>>>> missing >> >>>>> here? Do I have to eliminate the threads manually? If yes, how can I >> >>>>> do >> >>>>> that? >> >>>>> >> >>>>> An even bigger problem is, that if I dlopen() the same plugin again, >> >>>>> and call a libsecret function, then it just freezes with this: >> >>>>> >> >>>>> (process:18663): GLib-GObject-WARNING **: cannot register existing >> >>>>> type >> >>>>> 'SecretService' >> >>>>> (process:18663): GLib-GObject-CRITICAL **: >> >>>>> g_type_add_interface_static: >> >>>>> assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed >> >>>>> (process:18663): GLib-GObject-CRITICAL **: >> >>>>> g_type_add_interface_static: >> >>>>> assertion 'G_TYPE_IS_INSTANTIATABLE (instance_type)' failed >> >>>>> (process:18663): GLib-CRITICAL **: g_once_init_leave: assertion >> >>>>> 'result >> >>>>> != 0' failed >> >>>>> (process:18663): GLib-GIO-CRITICAL **: >> >>>>> g_async_initable_new_valist_async: assertion >> >>>>> 'G_TYPE_IS_ASYNC_INITABLE >> >>>>> (object_type)' failed >> >>>>> >> >>>>> Which seems to suggest that I need to unregister the SecretService >> >>>>> type >> >>>>> at dlclose(). Is that right? How can I do that? >> >>>>> >> >>>>> I don't have too much experience with glib, and I am just probably >> >>>>> doing something wrong, or missing something. Any help is >> >>>>> appreciated. I can >> >>>>> also put together a reproducible example if needed. >> >>>>> >> >>>>> Thanks, Best, >> >>>>> Gabor >> >>>>> _______________________________________________ >> >>>>> gtk-list mailing list >> >>>>> gtk-list@xxxxxxxxx >> >>>>> https://mail.gnome.org/mailman/listinfo/gtk-list >> >>>> >> >>>> -- >> >>>> https://www.bassi.io >> >>>> [@] ebassi [@gmail.com] >> >>> >> >>> >> >> -- >> >> https://www.bassi.io >> >> [@] ebassi [@gmail.com] >> > >> > >> >> >> >> -- >> https://www.bassi.io >> [@] ebassi [@gmail.com] > > -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
