GNOME Bugzilla – Bug 363019
gnome_keyring_get_default_keyring_sync returns NULL but no error code when no default keyring has ever been created
Last modified: 2019-02-22 11:46:01 UTC
In a bug report [1], in a gentoo system, gnome_keyring_get_default_keyring_sync is returning a NULL string, but the error code doesn't indicate any error. This doesn't make sense, sounds like a bug. [1] http://trac.gajim.org/ticket/2595
It's gnome-keyring 0.6.0 (last version in portage). I tried to rebuild it, same error. Thanks.
Created attachment 74929 [details] End of strace when segfaulting.
I tried to make the keyring python bindings accept NULL from gnome_keyring_get_default_keyring_sync and pass back NULL to the other APIs as a "keyring" parameter, but it doesn't work, I just get gnomekeyring.BadArgumentsError. Therefore this really is a bug, NULL is not a valid value.
I was able to reproduce this bug using a brand new user account. It appears the problem occurs when gnome_keyring_get_default_keyring_sync is called when the user has never before created a default keyring.
Thanks Gustavo, you're probably right : I have never created a keyring, simply because I don't know how to do it, and I don't see the utility of creating one : I don't even know for what that is used. On my system, gnome-keyring is installed, but gnome-keyring-manager is not, because I'm using gnome-light instead of the entire gnome desktop.
As far as I know, the default keyring should be created automatically when it is first requested by an application. That does not seem to happen. Anyway, gajim was now patched to work around this problem...
*** Bug 376183 has been marked as a duplicate of this bug. ***
I ran into this with seahorse, a simple NULL check sufficed (see bug #391699). But perhaps the default keyring should in fact be created. Alex, what do you think?
*** Bug 408064 has been marked as a duplicate of this bug. ***
*** Bug 455379 has been marked as a duplicate of this bug. ***
Please fix this bug. It causes a python interpreter to segfault.
I agree. I cant use gnome-keyring to store passwords in Conduit until this is fixed
I don't understand the bug. gnome-keyring-daemon is returning NULL which means 'there is no default keyring'.
When application wants to know what is the default keyring but there is no default keyring this is almost always an error because generally applications don't know the name of the missing default keyring. Additionally returning a null without an error causes python wraper to call PyString_FromString with null as an argument leading to segfault (see bug #455379). IMHO the best way to fix this bug is to raise an error when there is no default keyring.
Interesting, I'll think about that. On the other hand, please note that it's very rare that an application needs to know the name of the default keyring. It can just pass NULL instead of a keyring name to almost any function (the docs specify which ones, generally anything that doesn't modify/create/delete an entire keyring). In addition gnome_keyring_item_create creates a default keyring automatically. A suggestion, perhaps the python wrapper should return None when no keyring exists...
(In reply to comment #15) > Interesting, I'll think about that. > > On the other hand, please note that it's very rare that an application needs to > know the name of the default keyring. It can just pass NULL instead of a > keyring name to almost any function (the docs specify which ones, generally > anything that doesn't modify/create/delete an entire keyring). See Comment #3. I already tried passing NULL to other APIs and it doesn't work. > > In addition gnome_keyring_item_create creates a default keyring automatically. > > A suggestion, perhaps the python wrapper should return None when no keyring > exists... Again, in Comment #3 I tried it and didn't work. Unless things improved a lot in the mean time, because I tried it long ago...
I don't see any reason in using the name of the default keyring if it can be accessed by NULL. Therefore gnome_keyring_get_default_keyring is redundant.
(In reply to comment #16) > Again, in Comment #3 I tried it and didn't work. Unless things improved a lot > in the mean time, because I tried it long ago... Yes, things have improved in the mean time. I've gone over the gnome-keyring API, and documented it and made the handling of the default keyring more consistent in this release cycle. Try out the 2.19.5 release, for example.
Ok, I did check and you're right. So NULL is now a good value, not error for this API and the bug can be closed. I'll fix the Python bindings.