GNOME Bugzilla – Bug 677180
Doesn't save updated password
Last modified: 2012-07-19 13:02:15 UTC
empathy-3.4.1-1.fc17.x86_64 Every time I restart my machine from suspend, I have a few "chat account authentication failure" errors in gnome-shell, due to the way it handles passwords. 1. Create a new IM account with password 1, make Empathy remember the password in the keyring 2. Make sure you can access chat using that IM and password 3. Disable chat, change password 1 to password 2 using a web interface to the chat for example 4. Launch empathy's accounts window 5. See that there's an authentication failure, password entry pops up, enter password 2 At this point, password 2 should be remembered in the keyring just like password 1, or it should have given me the option to remember that password. It didn't. 6. Disable chat, restart chat, authentication failure
I just tested here using empathy-3.4.2.3-1.fc17.x86_64 and it worked fine (I cheated and just change the saved password using seahorse rather than in the IM service but that's the same). Could you check your Empathy.AuthClient logs (empathy-debugger), after entering the right password in the dialog I have: (empathy-auth-client:26804): empathy-DEBUG: find_items_cb: Got 1 secrets; use the first one (empathy-auth-client:26804): empathy-DEBUG: server_sasl_handler_ready_cb: Use retry password (empathy-auth-client:26804): empathy-DEBUG: empathy_server_sasl_handler_provide_password: Calling StartMechanismWithData with our password (empathy-auth-client:26804): empathy-DEBUG: empathy_server_sasl_handler_provide_password: remembering the password (empathy-auth-client:26804): empathy-DEBUG: empathy_server_sasl_handler_provide_password: MaySaveResponse unknown, assuming TRUE (empathy-auth-client:26804): empathy-DEBUG: auth_factory_new_sasl_handler_cb: New SASL server handler received from the factory (empathy-auth-client:26804): empathy-DEBUG: sasl_status_changed_cb: SASL status changed to 'in progress' (empathy-auth-client:26804): empathy-DEBUG: start_mechanism_with_data_cb: Started mechanism successfully (empathy-auth-client:26804): empathy-DEBUG: empathy_server_sasl_handler_provide_password: Calling StartMechanismWithData with our password (empathy-auth-client:26804): empathy-DEBUG: empathy_server_sasl_handler_provide_password: not remembering the password (empathy-auth-client:26804): empathy-DEBUG: empathy_server_sasl_handler_provide_password: MaySaveResponse unknown, assuming TRUE (empathy-auth-client:26804): empathy-DEBUG: start_mechanism_with_data_cb: Failed to start mechanism: Mechanisms can only be started in state Not_Started, not 1 (empathy-auth-client:26804): empathy-DEBUG: sasl_status_changed_cb: SASL status changed to 'server succeeded' (empathy-auth-client:26804): empathy-DEBUG: sasl_status_changed_cb: Saving password in keyring (empathy-auth-client:26804): empathy-DEBUG: empathy_keyring_set_account_password_async: Remembering password for gabble/jabber/cassidy_2dtest1_40jabber_2ebelnet_2ebe0
empathy/Tls-DEBUG: 12/07/12 10:50:54.743474: observe_channels: We have a retry password for account gabble/jabber/hadess_40chat_2efacebook_2ecom0, calling Claim empathy/Other-DEBUG: 12/07/12 10:50:54.744625: empathy_keyring_get_account_password_async: Trying to get password for: gabble/jabber/hadess_40chat_2efacebook_2ecom0 empathy/Other-DEBUG: 12/07/12 10:50:55.257555: empathy_keyring_set_account_password_async: Remembering password for gabble/jabber/hadess_40chat_2efacebook_2ecom0 But in seahorse the password isn't actually changed.
Can you search for 'gabble' in seahorse and check if the key isn't duplicated? Could you attach the full logs? Maybe more than one secret is stored and empathy picks the wrong one.
(In reply to comment #3) > Can you search for 'gabble' in seahorse and check if the key isn't duplicated? Not sure the search in seahorse works that well, searching for gabble ends up empty. Searching by hand for my facebook account, I can find, listed as "Instant Messaging Password", the correct password: account-id: gabble/jabber/hadess_40chat_2efacebook_2ecom0 param-name: password and listed as "Telepathy Password" (with the wrong password): param: password account: gabble/jabber/hadess_40chat_2efacebook_2ecom0 But more bizarre is my Google chat account. There's a single one with the wrong (old) password: param: password account: gabble/jabber/hadessuk_40googlemail_2ecom0 And no other password store. > Could you attach the full logs? How do I get those? I'm loading empathy-debugger as soon as I'm logged in and reproduced the problem. > Maybe more than one secret is stored and > empathy picks the wrong one. I'm guessing so from the above. Loading and saving from different stores? (account-id vs. account)
Google, marked as Instant Messenger (correct password): account-id: gabble/jabber/hadess_40hadess_2enet0 param-name: password Google, marked as Telepathy (old password): param: password account: gabble/jabber/hadess_40hadess_2enet0 Same account/account-id difference.
Ah I see! The "account" password is a legacy from mission-control while "account-id" is the one actually used by Empathy now. Empathy has code which is supposed to migrate the old MC passwords to the new schema. This migration code should be run only once but is not because of this MC bug: https://bugs.freedesktop.org/show_bug.cgi?id=42088 Maybe Empathy should just not update the password if there is already a passwore stored for this account using the new schema.
(In reply to comment #6) > Maybe Empathy should just not update the password if there is already a > passwore stored for this account using the new schema. Actually we can just remove this migration code, we are shipping it since a bunch of releases.
Created attachment 219019 [details] [review] remove MC password migration code We are shipping this since a bunch of releases so all passwords should be migrated since a while. Furthemore, it may cause issues when the password has been updated in Empathy but not MC.
Attachment 219019 [details] pushed as 7e7732c - remove MC password migration code
Will pointed out that you may be experiencing another issue (MC giving directly the old password to the CM, by-passing empathy-auth-client) so my patch may not have fix your issue. But we are about to remove gnome-keyring support from MC ( https://bugs.freedesktop.org/show_bug.cgi?id=32578 ) which should fix this case as well.