Bug 558678

Created attachment 386736 [details]
Testcase

Build testcase with:

gcc -o gktest -Wall `pkg-config --libs --cflags glib-2.0 gnome-keyring-1 uuid` gktest.c

Expected output is:

[dcbw@localhost krtest]$ ./gktest 
** Message: 
** Message: Add: item id 36 UUID 94489de8-80cc-4281-ada8-c18b6eee74d3 name 'Network secret for gk-test/wifi/psk'
** Message: 
** Message: Find: listing found keys
** Message:     Item 36: 'thesecret' (keyring: 'login')
** Message:       str: connection-uuid = 94489de8-80cc-4281-ada8-c18b6eee74d3
** Message:       str: setting-name = wifi
** Message:       str: setting-key = psk
** Message: 
** Message: Delete: removed item 36
** Message: 
[dcbw@localhost krtest]$ 

with possibly a different UUID and item ID.

Testcase currently fails with:

[adamw@adam Download]$ ./gktest
** Message:
** Message: Add: failed to add item: 5
** Message:
** Message: Find: find result was 9
** Message:
** Message: Delete: find result was 9
** Message: 

where of course error '5' is GNOME_KEYRING_RESULT_BAD_ARGUMENTS.  The testcase works as expected on F11 and F12, but not rawhide.

*** Bug 556879 has been marked as a duplicate of this bug. ***

oh, I should point out that previous gnome-keyrings were broken the same way - I'm not suggesting it's a regression in the -2 builds, just that the changes between -1 and -2 don't fix it.

(In reply to comment #4)
> I'm not suggesting it's a regression in the -2 builds, just that the changes
> between -1 and -2 don't fix it.
Yep, it was just a sync with git.

Some notes for myself:

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"

With the latest Rawhide it seems even worse: gnome-keyring doesn't seem to be providing even existing passwords to other apps. Evo asked me for my mailserver password, terminals keep asking me for my ssh passphrase. gnome-keyring-daemon is running...

Filed upstream with more findings: https://bugzilla.gnome.org/show_bug.cgi?id=608357

(In reply to comment #6)
> With the latest Rawhide it seems even worse: gnome-keyring doesn't seem to be
> providing even existing passwords to other apps. Evo asked me for my mailserver
> password, terminals keep asking me for my ssh passphrase. gnome-keyring-daemon
> is running...    
That's probably a startup issue, there are three autorun files now:
/etc/xdg/autostart/gnome-keyring-pkcs11.desktop
/etc/xdg/autostart/gnome-keyring-secrets.desktop
/etc/xdg/autostart/gnome-keyring-ssh.desktop

If you run `/usr/bin/gnome-keyring-daemon -f`, does it work? No problems here with Evo and ssh.

"That's probably a startup issue, there are three autorun files now:
/etc/xdg/autostart/gnome-keyring-pkcs11.desktop
/etc/xdg/autostart/gnome-keyring-secrets.desktop
/etc/xdg/autostart/gnome-keyring-ssh.desktop"

all three are enabled for my user, according to gnome-session-properties .

"If you run `/usr/bin/gnome-keyring-daemon -f`, does it work? No problems here
with Evo and ssh."

I'll check after my next reboot (just did today's Rawhide update).

OK, existing secrets seem to be working after a reboot - almost too well, in fact; the first time I try to ssh out it succeeded without even asking me for the passphrase once! is this normal? I've forgotten how it's supposed to behave, now...

(In reply to comment #9)
> OK, existing secrets seem to be working after a reboot - almost too well, in
> fact; the first time I try to ssh out it succeeded without even asking me for
> the passphrase once! is this normal? I've forgotten how it's supposed to
> behave, now...    
If you previously saved the password to keyring, then yes, it automatically unlocks the key on first use.

I've built gnome-keyring-2.29.5-4.fc13 which should hopefully fix the issue, please test.

Test cases still fail with gnome-keyring-2.29.5-4.fc13.x86_64:

[spot@pterodactyl ~]$ gcc -o gktest -Wall `pkg-config --libs --cflags glib-2.0 gnome-keyring-1 uuid` gktest.c 
gktest.c: In function ‘main’:
gktest.c:191: warning: zero-length gnu_printf format string
gktest.c:199: warning: zero-length gnu_printf format string
gktest.c:203: warning: zero-length gnu_printf format string
gktest.c:207: warning: zero-length gnu_printf format string
[spot@pterodactyl ~]$ ./gktest 
** Message: 
** Message: Add: failed to add item: 5
** Message: 
** Message: Find: find result was 9
** Message: 
** Message: Delete: find result was 9
** Message: 
[spot@pterodactyl ~]$ cd cvs/sandbox/gnome-python2-desktop/devel/gnome-python-desktop-2.29.1/examples/
[spot@pterodactyl examples]$ ./keyring.py 
Traceback (most recent call last):
  File "./keyring.py", line 94, in <module>
    login, password = get_login_password()
  File "./keyring.py", line 87, in get_login_password
    "\n".join((login, password)), True)
gnomekeyring.BadArgumentsError

Yeah, doesn't seem to help in 'real use' either; I've installed the update and have rebooted for an unrelated reason several times since, and it still prompts for wireless password every boot.

Okay, I've built gnome-keyring-2.29.90-1.fc13 now but don't see any difference since gnome-keyring-2.29.5-4.fc13. The only thing running in my Gnome session is `/usr/bin/gnome-keyring-daemon --daemonize --login`.

Both tests mentioned above create a record in keyring but fails to set the password (or perhaps there's a problem retrieving it). That's another issue...

** Message: Add: item id 30 UUID 93f404cd-3a57-4e22-b353-9b6b64a3f878 name 'Network secret for gk-test/wifi/psk'
** Message: 
** Message: Find: listing found keys
** Message:     Item 30: '' (keyring: 'login')
** Message:       str: connection-uuid = 93f404cd-3a57-4e22-b353-9b6b64a3f878
** Message:       str: setting-key = psk
** Message:       str: setting-name = wifi
** Message: 
** Message: Delete: removed item 30


  File "./keyring.py", line 28, in get_login_password
    login, password = secret.split('\n')
ValueError: need more than 1 value to unpack

Another try: gnome-keyring-2.29.90-2.fc13
So far both tests succeed here.

Nope. No good here. Tried rebooting and recreating the wireless connection several times, it never stored the passphrase.

(In reply to comment #15)
> Another try: gnome-keyring-2.29.90-2.fc13
> So far both tests succeed here.    

Hmm, FWIW, I'm seeing a problem that is best explained by this "fix"

http://git.gnome.org/browse/gnome-disk-utility/commit/?id=35b950b470239ed6ab2d31b7ab0c7ed3da68ee57

with libgnome-keyring-2.29.4-3.fc13.x86_64. The problem is that GNOME_KEYRING_RESULT_OK is returned when no password is actually returned. Might be related.

Same errors on both of the tests on my end. :(

(In reply to comment #17)
> with libgnome-keyring-2.29.4-3.fc13.x86_64. The problem is that
> GNOME_KEYRING_RESULT_OK is returned when no password is actually returned.
That's https://bugzilla.gnome.org/show_bug.cgi?id=608510#c7, backported to libgnome-keyring-2.29.4-4.fc13

libgnome-keyring-2.29.4-4.fc13 also fails both test cases in the same way as previous builds.

There's a known issue at the moment - keyrings are not created automatically so if you're testing with a new account, passwords won't get saved. I've created upstream bugreport https://bugzilla.gnome.org/show_bug.cgi?id=610270

Let me know if that's your case, I've been able to store document password from Evince into my existing keyring, though not from gvfs (looking at that now).

I'm using an existing account which has several secrets saved already.

on further consideration of the criteria, this is strictly a final blocker, not beta blocker.

I see some changes landed in response to your upstream report; any chance we could get a build with those to test?

A git checkout from today no longer has this problem...

gnome-keyring-2.29.92-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/gnome-keyring-2.29.92-1.fc13

(In reply to comment #25)
> A git checkout from today no longer has this problem...    
Cool, thanks for testing, so it really looks to be related to new keyring creation when there weren't any.

A libgnome-keyring update is pending, stay tuned.

gnome-keyring-2.29.92-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

yup, it looks good with 2.29.92-1 for me. Doesn't seem to need any libgnome-keyring changes. It's remembering my wireless password now :) Thanks Tomáš!

I guess we can close this now? Any reason to keep it open?

libgnome-keyring-2.29.92-git20100317.1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/libgnome-keyring-2.29.92-git20100317.1.fc13

the fixed version went into stable, and it's been behaving for me for a week - I think we can close this.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Alright, thanks for testing, feel free to report more bugs, the only one I'm aware of is bug 573202, linking to https://bugzilla.gnome.org/show_bug.cgi?id=612202 and https://bugzilla.gnome.org/show_bug.cgi?id=611584

libgnome-keyring-2.29.92-git20100317.1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Let's remove this from the [[Common F13 bugs]] page on the wiki when Beta is released:

http://fedoraproject.org/wiki/Common_F13_bugs#GNOME_cannot_store_new_secrets_.28passwords.29

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers