GNOME Bugzilla – Bug 534946
doesn't clean password when writting changes to an another gnome-keyring
Last modified: 2008-06-11 05:33:51 UTC
one example is described on https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/230660 the issue has been discussed on #evolution today, if an user has a password stored to the non default gnome keyring and change it the new version is stored in the default gnome keyring but the other one is not cleaned that can create issue since gnome-keyring look through all the available keyring to get the password and might get the old datas first and try to use those
reassigning bug to srang as discussed on irc
setting the correct assignee now
That's going to be tough. Evolution performs operations on whatever keyring happens to be the default and has no knowledge of which keyring that is nor whether it changed since the last session. It seems like either gnome-keyring or whatever package changed the default keyring from "default" to "login" ought to be responsible for migration of existing keys. This problem is not unique to Evolution.
> That's going to be tough. not really, before writting a new configuration you could search if the account has already a setting stored and clean this one before writting the new configuration
Original reporter: Firstly some time spans. Original system - debian (long time user), new system Ubuntu Hardy heron (brand new computer about December). I installed Hardy Heron and copied my home directory from Debian. Worked fine. Changed password in February (repeat long time ago). Change was accepted and working correctly, no issues. I recall some instances that the email would ask for passwords but problem would fix itself with next upgrade. I upgraded Hardy about 1 week before the bug report raised and it started for asking for passwords all the time. I had the store passwords box ticked and it never 'stuck'. So summary, Evolution was working fine then it was not. It was not a 'migration' because the password had been migrated ages ago to 'login', or perhaps it never was I may have had to enter it manually as part of the move from Debian, I honestly don't remember. If you want more clarification ask away.
Matt, better than that, when you find passwords and get the result, you make sure that we take from the default marked keyring. Currently we force it to store to the default marked one. But while fetching, we don't ensure that but just go with the first result. Instead, we need to see if the password is from the default keyring or not.
Yeah but that doesn't address the problem fully because the old password is still left behind. I can already see users getting confused about why Evolution asked for a password when they can already see it there in Keyring Manager (in a non-default keyring). Perhaps when fetching we should pick out results from the default keyring and delete all other results. /me is still annoyed that applications should have to deal with this...
You are right. Ideally when the default is changed by itself, the migration should be done by GKD.
Sounds like you are on the right track regarding passwords. Thanks. Next part of the story. The send function totally broke. Obviously the cause is the multiple keyring bug but there is something really strange about the send function causing a failure to close down evolution forcing me to kill application. I tracked with the camel trace (sorry did not store result). The get function requested the password but the send function never did, it kept trying to send again and again with the same bad password and continued to fail. This continued even after I hit cancel send and it should have stopped. (trace kept showing tries again and again...) The send receive dialogue left the screen but behind the scenes the attempted sends with failures continued. This continued and when I shut down evolution it appeared to hang, the trace showed this constant try to send that was never honoured. I was getting from memory a 300 error. I ended up killing evolution. Deleting the outbox item resolved the problem. With one keyring I no longer have this problem, it sends fine. If there is any strange hang on exit bugs it could be the failure of the send function to track password errors correctly and constantly retrying.
Please try to stick to one issue per bug. Otherwise it quickly becomes difficult for maintainers to track individual issues. What you're describing in comment #9 sounds very similar to the first part of bug #532472, for which a patch is available.
Yes that does sound like the problem thanks. It is strongly related because the problem occurred with the keyring error. Keyring error occurs on both send and receive.
*** Bug 535987 has been marked as a duplicate of this bug. ***
Created attachment 111934 [details] [review] Test patch Something like this should fix it.
That should work. The issue is more that we get the password from the correct keyring rather than cleaning up passwords from other keyrings, correct? I wonder, though, if we find a password matching our criteria in the wrong keyring whether we should at least emit a terminal warning or something saying so, and that we're ignoring it.
Fixed in stable/trunk.