This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 558678 - Apps cannot add new passwords - GNOME_KEYRING_RESULT_BAD_ARGUMENTS
Apps cannot add new passwords - GNOME_KEYRING_RESULT_BAD_ARGUMENTS
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gnome-keyring (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: Tomáš Bžatek
Fedora Extras Quality Assurance
:
: 556879 (view as bug list)
Depends On:
Blocks: F13Blocker/F13FinalBlocker
  Show dependency treegraph
 
Reported: 2010-01-25 19:36 EST by Adam Williamson
Modified: 2015-03-03 17:44 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-17 15:52:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Testcase (6.65 KB, text/plain)
2010-01-25 19:39 EST, Dan Williams
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 608357 None None None Never

  None (edit)
Description Adam Williamson 2010-01-25 19:36:49 EST
On current Rawhide, things keep prompting me for passwords; Evolution asks for Google calendar password every time it accesses it, even though the 'remember password' box is checked, and I'm prompted for my wireless key every time I connect to the network.

I did some diagnosis with Dan Williams, and he provided a test program which just does NetworkManager's key addition cycle and dumps debug info. From the output I provided, he says:

<dcbw> the error when adding is GNOME_KEYRING_RESULT_BAD_ARGUMENTS
<dcbw> using likely the exact same code we always have
<dcbw> could be that we're using it wrongly, but I doubt it

It seems that previously-stored passwords are still working okay, but no new ones can be written.

I have been testing with the brand new libgnome-keyring and gnome-keyring from Koji, versions 2.29.4-2.fc13 and 2.29.5-2.fc13 respectively.

Dan will attach his test code.
Comment 1 Dan Williams 2010-01-25 19:39:43 EST
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.
Comment 2 Dan Williams 2010-01-25 19:43:16 EST
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.
Comment 3 Matthew Barnes 2010-01-25 23:15:21 EST
*** Bug 556879 has been marked as a duplicate of this bug. ***
Comment 4 Adam Williamson 2010-01-26 02:55:17 EST
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.
Comment 5 Tomáš Bžatek 2010-01-26 12:02:31 EST
(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"
Comment 6 Adam Williamson 2010-01-27 12:14:09 EST
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...
Comment 7 Tomáš Bžatek 2010-01-28 12:52:13 EST
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.
Comment 8 Adam Williamson 2010-01-28 14:36:10 EST
"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).
Comment 9 Adam Williamson 2010-01-28 15:39:09 EST
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...
Comment 10 Tomáš Bžatek 2010-02-01 07:43:14 EST
(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.
Comment 11 Tomáš Bžatek 2010-02-08 09:15:53 EST
I've built gnome-keyring-2.29.5-4.fc13 which should hopefully fix the issue, please test.
Comment 12 Tom "spot" Callaway 2010-02-08 10:56:30 EST
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
Comment 13 Adam Williamson 2010-02-08 18:52:08 EST
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.
Comment 14 Tomáš Bžatek 2010-02-09 06:04:54 EST
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
Comment 15 Tomáš Bžatek 2010-02-16 11:00:32 EST
Another try: gnome-keyring-2.29.90-2.fc13
So far both tests succeed here.
Comment 16 Adam Williamson 2010-02-16 12:27:53 EST
Nope. No good here. Tried rebooting and recreating the wireless connection several times, it never stored the passphrase.
Comment 17 David Zeuthen 2010-02-16 12:48:52 EST
(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.
Comment 18 Tom "spot" Callaway 2010-02-16 12:56:53 EST
Same errors on both of the tests on my end. :(
Comment 19 Tomáš Bžatek 2010-02-17 09:55:28 EST
(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
Comment 20 Tom "spot" Callaway 2010-02-17 10:46:57 EST
libgnome-keyring-2.29.4-4.fc13 also fails both test cases in the same way as previous builds.
Comment 21 Tomáš Bžatek 2010-02-17 10:51:59 EST
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).
Comment 22 Adam Williamson 2010-02-17 14:13:24 EST
I'm using an existing account which has several secrets saved already.
Comment 23 Adam Williamson 2010-03-02 02:33:12 EST
on further consideration of the criteria, this is strictly a final blocker, not beta blocker.
Comment 24 Adam Williamson 2010-03-04 17:55:04 EST
I see some changes landed in response to your upstream report; any chance we could get a build with those to test?
Comment 25 Tom "spot" Callaway 2010-03-09 16:02:14 EST
A git checkout from today no longer has this problem...
Comment 26 Fedora Update System 2010-03-10 08:21:12 EST
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
Comment 27 Tomáš Bžatek 2010-03-10 09:35:45 EST
(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.
Comment 28 Fedora Update System 2010-03-11 08:30:11 EST
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.
Comment 29 Adam Williamson 2010-03-11 11:27:04 EST
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?
Comment 30 Fedora Update System 2010-03-17 11:23:07 EDT
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
Comment 31 Adam Williamson 2010-03-17 15:52:38 EDT
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
Comment 32 Tomáš Bžatek 2010-03-18 06:49:04 EDT
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
Comment 33 Fedora Update System 2010-03-23 20:42:51 EDT
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.
Comment 34 Paul W. Frields 2010-04-13 07:25:56 EDT
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
Comment 35 Adam Williamson 2010-04-13 13:06:52 EDT
-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers



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

Note You need to log in before you can comment on or make changes to this bug.