Bug 1032620 - Doesn't remember POP password
Summary: Doesn't remember POP password
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: evolution
Version: 21
Hardware: Unspecified
OS: Linux
high
unspecified
Target Milestone: ---
Assignee: Milan Crha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-20 13:43 UTC by Tim Waugh
Modified: 2015-12-02 16:07 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-02 03:02:40 UTC
Type: Bug


Attachments (Terms of Use)
DBus messages to/from gnome-keyring-daemon while starting evolution (5.00 KB, text/plain)
2013-11-21 14:23 UTC, Tim Waugh
no flags Details

Description Tim Waugh 2013-11-20 13:43:11 UTC
Description of problem:
I'm finding that evolution is not remembering the password for a configured POP account. This persists when deleting the account and adding it again.

Version-Release number of selected component (if applicable):
evolution-3.10.2-1.fc20.x86_64
evolution-data-server-3.10.2-1.fc20.x86_64
gnome-keyring-3.10.1-1.fc20.x86_64

How reproducible:
Happens every time for me.

Steps to Reproduce:
1.Add POP account.
2.Send/Receive
3.Close evolution
4.Start it again.

Actual results:
Asks for password at step 2.
Asks for password again at step 4.

Expected results:
Password is remembered at step 4.

Additional info:
I don't see the password in gnome-keyring.

Comment 1 Tim Waugh 2013-11-20 13:44:41 UTC
Even happens if I just click Send/Receive twice.

Comment 2 Tim Waugh 2013-11-20 14:16:06 UTC
Proposing as a blocker as per http://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Desktop_keyring

Comment 3 Tim Waugh 2013-11-20 16:25:45 UTC
A similar issue seems to affect calendars: logging out and logging in again causes password prompts for every configured calendar.

Comment 4 Tim Waugh 2013-11-20 17:23:12 UTC
Strangely, this is working now. I'm not entirely sure what changed. I was trying to debug the issue by watching DBus messages, and now the passwords seem to be remembered.

Weird... I will reopen if I figure out the cause.

Comment 5 Adam Williamson 2013-11-20 17:24:18 UTC
Discussed at 2013-11-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-20/f20-blocker-review.2013-11-20-17.00.log.txt . This is provisionally accepted as a blocker: if it's reproducible as described we would consider it to be a blocker. roshi (Mike Ruckman) will attempt to reproduce the bug and mark it as an accepted blocker if he finds it is as described; if not, we will discuss it again at the next blocker review meeting.

Comment 6 Mike Ruckman 2013-11-20 22:08:34 UTC
Installed Final TC1 to a fresh VM, added a POP account to Evolution. Saved password to the keyring, and never had to enter it again. Leaving bug as is.

Comment 7 Milan Crha 2013-11-21 07:43:48 UTC
(In reply to Tim Waugh from comment #4)
> Strangely, this is working now. I'm not entirely sure what changed. I was
> trying to debug the issue by watching DBus messages, and now the passwords
> seem to be remembered.
> 
> Weird... I will reopen if I figure out the cause.

All the password management is done on the evolution-source-registry side, and it happens sometimes (quite rarely for me, even still annoying), that libsecret doesn't connect (I think) to its counterpart properly for some reason, which makes all passwords forgotten and user is forced to reenter them. Sadly the entered password is not saved either. I suppose something like this happened to you too. I do not know, but one theory was that the evolution-source-registry process is run before the libsecret, thus it doesn't get connected properly. In any case usual fix is a re-start of all running evolution processes, (if under gnome-shell, then evolution-calendar-factory as the last, because it's auto-restarted there).

Comment 8 Tim Waugh 2013-11-21 11:59:57 UTC
OK, I'm seeing this right now. What diagnostics would you like?

Comment 9 Tim Waugh 2013-11-21 12:05:48 UTC
Here's one datapoint: the requested e-source-uid values don't match any of the keys in my keyring, whereas when everything is working they do match.

$ dbus-monitor --session interface='org.freedesktop.Secret.Service'
signal sender=org.freedesktop.DBus -> dest=:1.97 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.97"
method call sender=:1.37 -> dest=:1.10 serial=356 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384954518.14917.17@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=357 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=GetSecrets
   array [
      object path "/org/freedesktop/secrets/collection/login/1576"
   ]
   object path "/org/freedesktop/secrets/session/s2"
method call sender=:1.37 -> dest=:1.10 serial=358 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384954518.14917.17@rubik"
      )
   ]
signal sender=:1.10 -> dest=(null destination) serial=496 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=CollectionChanged
   object path "/org/freedesktop/secrets/collection/login"
method call sender=:1.37 -> dest=:1.10 serial=387 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163047.2561.19@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=388 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163047.2561.19@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=393 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163187.2561.39@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=395 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163187.2561.39@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=399 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163011.2561.14@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=400 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163011.2561.14@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=411 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384162932.2561.4@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=412 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384162932.2561.4@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=426 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384162977.2561.9@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=428 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384162977.2561.9@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=433 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163221.2561.44@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=434 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163221.2561.44@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=438 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163117.2561.29@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=439 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163117.2561.29@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=475 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163187.2561.39@rubik"
      )
   ]
method call sender=:1.37 -> dest=:1.10 serial=476 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163187.2561.39@rubik"
      )
   ]

There are no keys matching "14917" (in Passwords and Keys, Passwords->login, putting "14917" in the filter box).

For "2561" the only keys are:
Evolution Data Source 1384163084.2561.24@rubik
Evolution Data Source 1384163153.2561.34@rubik

Comment 10 Tim Waugh 2013-11-21 12:08:13 UTC
Not sure if it's related: while reading through mail, the unread message count is not changing at all.

Comment 11 Tim Waugh 2013-11-21 12:15:35 UTC
After restarting, unread message counts are updating, so I guess that was an unrelated bug.

Could this forgotten-passwords bug be related to goa-daemon crashing? I'm also seeing bug #1031662.

Comment 12 Tim Waugh 2013-11-21 14:21:31 UTC
(In reply to Milan Crha from comment #7)
> I do not know, but one theory was that the
> evolution-source-registry process is run before the libsecret, thus it
> doesn't get connected properly.

So, I see evolution-source-registry as PID 1986... but gnome-keyring-daemon (is that what you meant by libsecret) is PID 1649.

> In any case usual fix is a re-start of all
> running evolution processes, (if under gnome-shell, then
> evolution-calendar-factory as the last, because it's auto-restarted there).

I'll try that shortly.

Further to comment #9, .config/evolution/sources has these sources:

1241181522.20211.26@worm.elk.source
1241542204.19984.1@worm.elk.source
1320148696.31410.5@worm.elk.source
1348585860.1585.2@localhost.source
1348585860.1585.3@localhost.source
1359477224.12743.15@rubik.source
1359477224.12743.18@rubik.source
1359477224.12743.26@rubik.source
1384162932.2561.4@rubik.source
1384162977.2561.9@rubik.source
1384163011.2561.14@rubik.source
1384163047.2561.19@rubik.source
1384163084.2561.24@rubik.source
1384163117.2561.29@rubik.source
1384163153.2561.34@rubik.source
1384163187.2561.39@rubik.source
1384163221.2561.44@rubik.source
1384954518.14917.12@rubik.source
1384954518.14917.17@rubik.source
1384954518.14917.26@rubik.source
local.source
vfolder.source

For comparison, gnome-keyring lists these keys as matching "evolution":

Evolution Data Source 1320148394.31410.2@worm.elk
Evolution Data Source 1320148455.31410.3@worm.elk
Evolution Data Source 1320148768.31410.6@worm.elk
Evolution Data Source 1320148897.31410.8@worm.elk
Evolution Data Source 1339575942.16936.1@rubik.elk
Evolution Data Source 1347019761.6661.1@rubik.elk
Evolution Data Source 1348589942.2761.0@localhost
Evolution Data Source 1348659056.20613.0@rubik
Evolution Data Source 1354181928.1745.6@rubik
Evolution Data Source 1354182186.1745.12@rubik
Evolution Data Source 1358341218.1835.0@rubik
Evolution Data Source 1384163084.2561.24@rubik
Evolution Data Source 1384163153.2561.34@rubik

I have 2 mail accounts configured requiring passwords, and 10 CalDav calendars requiring passwords.

Comment 13 Tim Waugh 2013-11-21 14:23:41 UTC
Created attachment 827230 [details]
DBus messages to/from gnome-keyring-daemon while starting evolution

Here's the D-Bus conversation again, this time with replies.

Is evolution-data-source asking for the wrong source ID? Are the source IDs not stable in some way?

Comment 14 Milan Crha 2013-11-21 15:17:10 UTC
Hmm, too many questions/concerns. Let's deal with this randomly:

a) not updated unread counts, you probably see:
   https://bugzilla.gnome.org/show_bug.cgi?id=711443

b) persistent source ID: yes, they are supposed to be persistent, only with
   some exceptions, like GOA accounts, which are tight to GOA ID.
   Such generated sources live in ~/.cache/evolution/sources

c) when you mention GOA, do you have your POP account configured through it?

Comment 15 Tim Waugh 2013-11-21 15:41:11 UTC
(In reply to Milan Crha from comment #14)

> b) persistent source ID: yes, they are supposed to be persistent, only with
>    some exceptions, like GOA accounts, which are tight to GOA ID.
>    Such generated sources live in ~/.cache/evolution/sources

I just have a 'trash' directory there.

> c) when you mention GOA, do you have your POP account configured through it?

No, I don't.

Comment 16 Tim Waugh 2013-11-21 15:59:38 UTC
I closed evolution and killed the evolution processes in the order you said, evolution-calendar-factory last. 'ps axf | grep [e]vol' shows no processes. Shortly afterwards, both evolution-calendar-factory and evolution-source-registry were restarted automatically, and I was prompted for several passwords again.

So, once this has happened, simply killing evolution processes does not fix the problem.

However, from snooping on the D-Bus session I found that at least one password is now working correctly, this one:

method call sender=:1.342 -> dest=:1.10 serial=202 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
   array [
      dict entry(
         string "e-source-uid"
         string "1384163084.2561.24@rubik"
      )
   ]
method return sender=:1.10 -> dest=:1.342 reply_serial=202
   array [
      object path "/org/freedesktop/secrets/collection/login/1583"
   ]
   array [
   ]

Note that it had *not* asked for this e-source-uid previously.

For some reason, evolution is not asking for the correct e-source-uid secrets in some situations.

Comment 17 Tim Waugh 2013-11-21 16:29:42 UTC
I've restarted the system and logged in, and I am still prompted for passwords.

Just to be clear: this was all working fine yesterday (comment #4). The required passwords are still there in gnome-keyring, but evolution is asking for the wrong e-source-uids.

Comment 18 Milan Crha 2013-11-25 12:55:19 UTC
Could you replace /usr/libexec/evolution-source-registry with a script, which will run the original evolution-source-registry, only with redirected output to a file, thus it'll be easier to see what happened in the background, please? Say something like:
   $ cd /usr/libexec
   $ mv evolution-source-registry evolution-source-registry.orig
   $ nano evolution-source-registry

       #!/bin/bash
       echo "-------------------" >> /tmp/esf-log.txt
       date >> /tmp/esf-log.txt
       echo "-------------------" >> /tmp/esf-log.txt
       /usr/libexec/evolution-source-registry.orig & >> /tmp/esf-log.txt

   $ chmod a+x evolution-source-registry
   $ restart

which also distinguishes between different runs by adding a delimiter to the /tmp/esf-log.txt file. evolution-source-registry tends to write errors on the console, thus this may help, I hope.

Comment 19 Tim Waugh 2013-11-25 13:07:25 UTC
Since last week I've had to provide all my passwords in order to get some things done, so we'll have to wait for this problem to happen again before having a chance to debug it.

In the mean time, I'll put a script there as you suggest.

Comment 20 Adam Williamson 2013-11-27 17:11:54 UTC
Discussed at 2013-11-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-27/f20-blocker-review-3.2013-11-27-17.01.log.txt . As no-one else seems to have run into this kind of problem in desktop validation testing, we're satisfied the keyring stuff is basically working, and Tim's just running into some sort of unusual case, so this does not need to block the release.

Comment 21 Norman Smith 2014-02-25 22:04:48 UTC
This bug is still lurking.

gnome-shell-3.10.3-8.fc20.x86_64
evolution-3.10.4-1.fc20.x86_64
evolution-data-server-3.10.4-1.fc20.x86_64
gnome-keyring-3.10.1-1.fc20.x86_64

I have four pop accounts with passwords. In the past a password for one or other account appeared to be forgotten on rare occasions. Entering it when prompted always cleared the problem.  Today evolution forgot the passwords for all of my accounts and he did not remember them when passwords were re-entered.  I logged out and logged back in and the problem continued.  After rebooting and powering down and then restarting I was able to re-enter the passwords and they were remembered. I suspect the power down did not really have anything to do with the problem going away.
  
I wrote a script as recommended in Comment 18 but I changed:

FROM /usr/libexec/evolution-source-registry.orig & >> /tmp/esf-log.txt

TO   /usr/libexec/evolution-source-registry.orig >> /tmp/esf-log.txt &

Re-direction must be done before executing in the background.

If this happens again I will post the log.

Comment 22 Milan Crha 2014-02-26 09:56:41 UTC
(In reply to Norman Smith from comment #21)
> FROM /usr/libexec/evolution-source-registry.orig & >> /tmp/esf-log.txt
> 
> TO   /usr/libexec/evolution-source-registry.orig >> /tmp/esf-log.txt &
> 
> Re-direction must be done before executing in the background.

No, the meaning of "&>>..." is different from ">>...&", the first means redirect all output streams into the file and wait for the end of application, while the second redirects only stdout to a file (completely omitting stderr) and run in the background, with immediate end of the script. Try 'man bash' and search for "Redirecting Standard Output and Standard Error" section, together with the following "Appending Standard Output and Standard Error" section.

Comment 23 Norman Smith 2014-02-26 12:35:09 UTC
Hello Milan:

You are correct. I am well aware of the function of &>> but there is a space between the & and the >> in comment 18. I should not of taken your comment literally. I should have realized it was just a typo error.

Comment 24 Fedora Admin XMLRPC Client 2014-09-04 14:29:56 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 25 Robert Buchholz 2014-09-23 07:59:59 UTC
I am seeing this issue after upgrading evolution-data-server from 3.10.4-4.fc20 to 3.10.4-5.fc20. Evolution kept asking for passwords when receiving or sending emails every single time.
The problem went away after downgrading.

Comment 26 Milan Crha 2014-09-24 06:42:16 UTC
(In reply to Robert Buchholz from comment #25)
> I am seeing this issue after upgrading evolution-data-server from
> 3.10.4-4.fc20 to 3.10.4-5.fc20. Evolution kept asking for passwords when
> receiving or sending emails every single time.
> The problem went away after downgrading.

Thanks for the update. You are the second reporting this. There had been no change regarding POP passwords in that particular update, though. Password issues are usually caused by an issue with libsecret, which connect to gnome-keyring (or kwallet), which exposes org.freedesktop.secrets D-Bus service. This all is done on the evolution-source-registry side. By any chance, did you restart the system after the upgrade to 3.10.4-5? Does the same happen if you run:
   $ /usr/libexec/evolution-source-registry
from a console? Does it print any critical warnings there?

I ask, because there are also people reporting correct behaviour after the update.

Comment 27 Tim Waugh 2015-01-20 09:47:56 UTC
This just happened again, but I'm afraid the script was not in place. :-(

I found that logging out and logging in again without entering the passwords it was asking for (calendars and POP3 mail) made it remember them again.

These journal entries look suspicious:

Jan 20 09:32:55 rubik org.gnome.evolution.dataserver.Sources3[2076]: ** Message: received an invalid or unencryptable secret

I got 37 of them on the failed login which asked for passwords, and none on "normal" login (like this one) where it remembers them.

Comment 28 Tim Waugh 2015-01-20 09:48:27 UTC
I should mention versions:
evolution-3.12.9-1.fc21.x86_64
evolution-data-server-3.12.9-2.fc21.x86_64

Comment 29 Milan Crha 2015-02-04 15:00:28 UTC
That looks like an error returned by libsecret. I believe the logout & login restarted the background libsecret service and everything went working normal again.

Comment 30 Fedora End Of Life 2015-11-04 15:42:06 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 31 Fedora End Of Life 2015-12-02 03:02:45 UTC
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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