OK, got it.
I am trying to write a binding that applied to as many Linux installations as possible, so I guess this is an exception then. For my use case, depending only on (lib)dbus would be ideal (for the users), because that should be present, independently of the desktop environment, and even on servers (although on servers gnome-keyring and KWallet are usually missing I guess).
I don't want to use that Python module, just wondered if there are any examples for accessing the keyring through dbus, without libsecret.
Anyway, this was very useful for me, thanks again!
Gabor
On Sun, Feb 5, 2017 at 3:46 PM, Emmanuele Bassi <ebassi@xxxxxxxxx> wrote:
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@gmail.com > 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@gmail.com > 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@gmail.com > 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@gmail.com > 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
