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]
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
