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 608357 - Unable to create new record
Unable to create new record
Status: RESOLVED FIXED
Product: gnome-keyring
Classification: Core
Component: general
2.29.x
Other Linux
: Normal major
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2010-01-28 17:17 UTC by Tomas Bzatek
Modified: 2010-02-07 18:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gnome-keyring-2.29.5-create-item-lookup.patch (619 bytes, patch)
2010-01-28 17:47 UTC, Tomas Bzatek
none Details | Review

Description Tomas Bzatek 2010-01-28 17:17:56 UTC
(originally filed as https://bugzilla.redhat.com/show_bug.cgi?id=558678)

Calling gnome_keyring_item_create_sync() with NULL as a first parameter (i.e. use default keyring) returns GNOME_KEYRING_RESULT_BAD_ARGUMENTS, the dbus communication is as follows:

method call sender=:1.183 -> dest=org.freedesktop.secrets serial=6
path=/org/freedesktop/secrets/aliases/default;
interface=org.freedesktop.Secret.Collection; member=CreateItem

error sender=:1.179 -> dest=:1.183
error_name=org.freedesktop.Secret.Error.NoSuchObject reply_serial=6
   string "The '/org/freedesktop/secrets/aliases/default' object does not
exist"


I've checked the code, looks like GkdSecretObjects.aliases hash table is always empty, the only way to fill it up is to call gkd_secret_objects_set_alias(). The aliases functionality is new to gnome-keyring, not sure what the original intentions were.

By further analysis, gkd_secret_util_parse_path() properly parses the path string (and sets *collection), parse_object_path() then tries to lookup an _item_ which of course doesn't exist. No need to return FALSE when we want to create new item.
Comment 1 Tomas Bzatek 2010-01-28 17:47:01 UTC
Created attachment 152503 [details] [review]
gnome-keyring-2.29.5-create-item-lookup.patch

Something like this, except I don't have idea what other functionality would it affect. So far I noticed seahorse reporting keyrings I haven't seen before ("default_1"...). The rest of the code works fine though, item can be created, read and deleted (see the testcase in https://bugzilla.redhat.com/show_bug.cgi?id=558678#c1).
Comment 2 Jürg Billeter 2010-01-30 10:12:38 UTC
When testing with evince, I don't see a difference with and without the patch applied. I always get the above error back via D-Bus when evince tries to store the password. I've tried with my old pre-2.29 keyring and also without any preexisting keyrings, always the same result.
Comment 3 Stef Walter 2010-02-07 18:12:46 UTC
I just committed a bunch fixes just went into gnome-keyring. There was some strange stuff going on. But I believe these issues (as you noted, there were several) have now been fixed. Some of the related commits:

commit aa548019df045b4085c088c84aec585ab0e62a98
Author: Stef Walter <stef@memberwebs.com>
Date:   Sun Feb 7 17:32:57 2010 +0000

    [pkcs11] Set attributes on object before storing.
    
    Set attributes on new objects before storing them.

commit 701cab2c3b40216c01bf1cda23fe15c9ff0d7caa
Author: Stef Walter <stef@memberwebs.com>
Date:   Sat Feb 6 15:39:05 2010 +0000

    [secrets] Fix problems with collection reloading.
    
    The module had a bug which would cause collections that were reloaded
    to appear as new collections

commit 4d22df25dac5c051c04f8d957169ff5ba45b5020
Author: Stef Walter <stef@memberwebs.com>
Date:   Sat Feb 6 15:06:16 2010 +0000

    [dbus] Refresh and store the default keyring correctly.
    
    Although the default keyring was being loaded, it was not being
    used correctly by the path resolution code.