GNOME Bugzilla – Bug 546406
Evolution does not like changed password on IMAP
Last modified: 2008-10-06 13:03:40 UTC
I got armtwisted (IS&T) to change my password for the mail. I use IMAP. Now Evolution is just completely insane. 1/ it does not ask me for a new password for said IMAP account 2/ it perpetually wait on "Checking for new mail" for said account. 3/ any delete operation on any other IMAP account is not performed 4/ when I want quit Evolution, I can't. I have to use killev. I don't find the passwords in the keyring or seahorse. I deleted the relevent lines in ~/.gnome2_private/Evolution Disable the guilty account work around the problem. In the end there are TWO problem. #1 why does not it ask for a new password? Getting "authentication failed" from IMAP should trigger that #2 why does this hang the other connections? I thought Evolution was abusing threads for that.
Because Evo is braindead here? I changed my gmail password and had to tell Evo to forget ALL my passwords because I also only got an "authentication failed" message instead of an "enter password" dialog. Reentering passwords for my 10 accounts is awesome, make sure you have written all of them down before to avoid bad surprises. ;-) I wonder if Matthew or Srini have any idea how to improve this for 2.26, or if I/we are doing something wrong here (if so, it's not obvious on how to behave as an average user). And there should be enough users that are urged to change their passwords regurlarly in a company environment for security reasons, so I consider this a major issue.
I fixed something similar to this for SMTP recently, which may also be applicable to IMAP. The basic flaw in the logic was that Evolution assumed cached passwords are always _valid_ passwords, so you get into these stupid busy loops: 1. Request authentication with server. 2. Server demands a password. 3. Do we have a cached password? We do! Send it. 4. Server rejects password: "Authentication Failed" 5. Goto step 1. The fix for SMTP was: 4.5. If rejected, delete cached password. then on the next pass, step 3 would prompt the user for a new password.
and where are these cached passwords so that one can nuke them?
Depending on how your distro configures Evolution-Data-Server, either in Gnome-Keyring or in ~/.gnome2_private/Evolution.
can't find them in the keyring and already removed the relevant lines in ~/.gnome2_private/Evolution as stated earlier.
I have an awesome news: File -> Forget Passwords does not even work. No password is asked and I still can't check my work email over IMAP.
see bug 548319: my Evo passwords are in a different keyring and seahorse is being uncoperative. This does not make this bug invalid, it just provide more cause as to where the problem could be. When I finally changed the password in Seahorse, it started to work. Nonetheless I should'nt even need to put my nose in that.
Created attachment 119663 [details] [review] Proposed patch Hmm, My earlier patch http://bugzilla.gnome.org/attachment.cgi?id=111934&action=view on bug #534946 put it at the right place, but the hunk moved out on commit :(. So its sort of partly worked. This should fix it fully
Created attachment 119664 [details] [review] just this fix Earlier patch has some other unintended changes also. Ignore it.
Looks correct to me, though I wonder if we should migrate and try the password from the non-default keyring if we don't find one on the default keyring, rather than just ignoring it. Then if it doesn't work it should get deleted and the user will be prompted. Might avoid an unnecessary password prompt. I'm okay with it going in as is, though. We could do the migration thing as a separate enhancement, unless you think it's a bad idea.
Matt, I seriously think that its a job of the gkd manager.
Done to stable/trunk
(In reply to comment #11) > Matt, I seriously think that its a job of the gkd manager. I can live with that. :)
(In reply to comment #13) > (In reply to comment #11) > > Matt, I seriously think that its a job of the gkd manager. > > I can live with that. :) > Checkout bug 548456 They apparently disagree.