GNOME Bugzilla – Bug 603855
Evolution fails to save passwords for accounts
Last modified: 2015-05-13 05:37:51 UTC
This is the first time I file a bug upstream, so sorry if it isn't reported properly, or if I've chosen the wrong component. This bug had been filed at https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/372089, which summarises best the problem being experienced by a number of users for months. Basically, when Evolution is set to remember passwords (for POP accounts in my case), the expected behaviour is for it to retrieve messages automatically without asking for passwords. Instead, the application keeps asking for them as though it failed to saved them. If instructed to forget passwords, it will then ask for them once again, and will work for some time properly, until it asks for them again. If the application is removed/re-installed the behaviour may change for some time before falling back to its previous behaviour. The same goes with fresh OS installation, as some report. If keyring default password is removed/changed, the problem will persist. In addition, some users, as pointed out in the above link, are worried about security breaches in our systems, any time Evolution displays the aforementioned behaviour. Without mentioning that the issue is particularly irksome, especially for users who own more than one account, and passwords are particularly long and/or difficult to remember. In turn, this has negative effects on users' productivity, and some state to be forced by this issue to get back to Thunderbird or, worse, Windows, in order to have a fully functioning working environment. Many thanks for your time.
Created attachment 149171 [details] Screenshot 1
Created attachment 149172 [details] Screenshot 2
Created attachment 149173 [details] Screenshot 3
I'm adding a few screenshots, hoping they help. Screenshot 1.png is the first warning to pop, here (probably because it refers to Alice, the name of the first account - being first in the list). If I do what it asks, it will not download any mail. Instead, it will disappear to let the second warning pop up, here shown in Screenshot 2.png. Again, if I enter my password it won't retrieve any new e-mail, but will disappear to let yet another warning appear, here shown in Screenshot 3.png. This one still refers to the second account, but the warning appears slightly different (no explanations). At this point, I can keep entering the requested password for the whole day long, nothing will happen other than the same window popping up again and again. If I hit Cancel, then Evolution will remain quiet until I notice it hasn't downloaded my mail for hours, and manually try to do so by clicking the relevant button. Which basically triggers the same response from Evolution. Usually this vicious circle is broken by quitting and restarting the application, after which passwords are requested, entered, and remembered for a varying (usually short) period of time.
I see the same behavior. Any idea where the issue might be?
*** Bug 638721 has been marked as a duplicate of this bug. ***
I too see this, and it finally occurred to me that it seems to coincide with general IMAP server responsiveness problems. And this has led me to make the observation that perhaps what the code is doing (rather than forgetting the password) is *assuming* that if evolution cannot connect to the IMAP or POP server, that it MUST be a bad password to which it prompts for a new one. If this is true, then it certainly adds to the confusion we're observing (e.g. it works, then it doesn't, then it does again). It's possible that what's really the bug is an unclear GUI. Namely, if instead of a dialog box prompting for a password and OK/Cancel buttons it should be a DB notifying the failure and then have just OK/ChangePassword buttons to which ChangePassword would take you to the Change Passowrd dialog. Anyway, just a thought...seems like this bug has been around a LONG time...too long for it to be an obvious one. Regards, == k+ ==
I see the same behaviour. But I've been seeing it for years. It's been like this since evolution was released years ago, and for a person like me who has 20 accounts it is beyond annoying. It occurs when evolution strikes some error when authenticating the password, which means the login fails. Evolution's response to this is to prompt for the password. That is perfectly reasonable, the problems arise in how Evolution implements it: 1. The first one is it does it on _any_ error, not just an "authentication failed" response from the server. This would only be a minor irritation if it didn't forget passwords, but ... 2. The second one is it always clears the existing password before prompting. This might be a reasonable thing to do if it only prompted when the server reported a login failure, I say might because even then some network problem may have corrupted the data sent, or the user might want to fix the problem by changing the password at the server end. But given it does clear it, asking for a password on any network failure is absolutely the wrong thing to do. 3. Occasionally, network errors will cause it to forget passwords for another service. For example today I had a change of SMTP submission password. That caused Evolution to forget the POP3 password for the same account. Once I figured out what was going on I changed the SMTP password several times to verify what was going on. the behaviour is 100% reproducible, and occurring even after reboot.s 4. The "he's got the wrong password flag" seems to stick on occasion. As in you get prompted for the password, enter using copy and paste, and Evolution says its wrong and prompts for it again. Killing evolution and restarting it is the only way curing of it of prompting for the password over and over again. Sometimes this "wrong password" flag seems to infect other accounts, and Evolution thinks every login fails. So on a bad day you will start evolution just when a network outage occurs, and _every_ password will be forgotten. In my case there is over 20 of then. You re-enter them all and guess what - you get hit by bug 4 and none of them are saved. So you have to kill Evolution, restart it and enter the 20 passwords *again*. There are obviously several bugs here, and given the amount of time they have been around they must be very well hidden. But all they would be a minor irritation if evolution didn't clear the password on an authentication error, because after all, all you would have to do if it didn't clear it is click OK to the password prompt. I am guessing the password is cleared to prevent evolution from trying to log in multiple times with a bad password. Bad design decision. If you think the password is suspect maybe you could set a "prompt for password at next login" flag. Or maybe it isn't a real problem because Evolution stops and prompts anyway, so repeated logins won't happen without human interaction. Whatever - but under no circumstances should you respond by clearing it. Never clear a password without being explicitly asked to. Clearing it was a lazy hack from someone who didn't want to introduce another flag they had to save in the account information.
Until 3.4 Evolution only saved passwords in case of a successful connect. Is this still an issue in recent versions?
Absolutely.(In reply to comment #9) > Until 3.4 Evolution only saved passwords in case of a successful connect. > > Is this still an issue in recent versions? Yes. I am currently using Debian unstable witch is 3.4.3. Last week it lost all 20 or so of my passwords again.
If this comes after some connection problems, I think it's a dupe of bug 409525
*** Bug 587461 has been marked as a duplicate of this bug. ***
There are quite few things being discussed here. First of all, some protocols do not define how to recognize precisely the issue with the authentication and other issues being caused during the authentication negotiation. Evolution did return the server-returned error (it's that "-ERR" line in the screen shots), but it also did forget the password. Forgetting passwords for errors is wrong. It was changed to not do that, thus the password prompt opened prepopulated with the old password. Then this behaviour as dropped, because gcr-prompt didn't allow it. The current stable version 3.16.x series has this ability returned back. There could be sometimes an issue in the libsecret which failed to talk to gnome-keyring daemon and didn't provide passwords for some reason. It still happens from time to time. That exhibits with empty password prompts. These can be cancelled now and after evolution processes restart the passwords are properly read from the key ring, they are not forgotten.