Bug 1011316

Thanks for a bug report. I suppose you did restart the machine after update, to give a chance to running processes to load their updated versions, right? I'm asking just in case.

Despite you do not save passwords into keyring, it's still used through libsecret to store the entered passwords into active session, from which I guess either some timeout was reached and the password was dropped from the session keyring, or the libsecret/keyring connection went crazy on the evolution-source-registry side and reported some failure there. I mention evolution-source-registry process, because it's responsible for all password management in evolution.

As far as I can tell, the libsecret doesn't restart gnome-keyring daemon if it lost connection to it, thus could it be that the gnome-keyring-daemon was restarted while evolution-source-registry was running, which made the connection to it from source registry invalidated? You can test by the machine restart, which is simpler than kill of evolution* processes, especially under gnome-shell, which auto-starts evolution-calendar-factory (you might kill the calendar factory as the last process from evolution processes there, because the gnome-shell restarts it, and its restart means the evolution-source-registry will be started as well).

You can also run /usr/libexec/evolution-source-registry from a console, which prints many debugging information there. if you also export GCR_DEBUG=all on the source registry console before its start, then you'll see debugging information from gnome keyring itself.

I moved /usr/libexec/evolution-source-registry to evolution-source-registry.orig and wrote a wrapper-script exporting GCR_DEBUG=all and starting evolution-source-registry.orig.
Everything was fine since I did it.
I replaced the wrapper with the original today and everything still is fine.

When I did some tests before opening this bug I only stopped evolution, not all the helpers. Probably during bootup the initialization of evolution-source-registry did not happen correctly. And know the restart of evolution-source-registry fixed this now.

I will have a look what happens after next restarts, if the initialization problem happens more often or was an exception.

(In reply to Oliver Paukstadt from comment #2)
> Probably during bootup the initialization of
> evolution-source-registry did not happen correctly. And know the restart of
> evolution-source-registry fixed this now.

I'm pretty sure it's the reason. I'd return back the script, thus you get the log of activity even for process run by D-Bus itself, and can look on it in the future, when you spot the issue (I believe you did that already).

I'm not sure if it's the same bug, but Evolution repeatedly prompts me for passwords for Gmail calendars that I am subscribed to that are not password protected.  Would that be related, or should I file a new bug?

(In reply to Matthew Saltzman from comment #4)
> I'm not sure if it's the same bug, but Evolution repeatedly prompts me for
> passwords for Gmail calendars that I am subscribed to that are not password
> protected.  Would that be related, or should I file a new bug?

It depends. If you connect to the read-only calendar through On The Web (with an ics file URL), then you might not be asked, unless necessary (it may also depend on the Username, whether filled or not). If you access the calendars through CalDAV, then it sort of makes sense it asks you for the password. Of course, you should be asked only once, if you save the password in the keyring.

I connect through my gmail online account.  It's not so terrible that it asks for a password and it should save it in the keyring.  The problem seems to be that, because there is no password on those calendars, nothing is saved in the keyring.  So (speculating here) the next attempt to read the calendar results in a password prompt again.  The null password isn't saved, so the process repeats endlessly.  

Another possibility is that it's Google and I use two-factor authentication, but the password prompter doesn't know how to handle that.  The Online Accounts service now does know how to handle two-factor authentication, but because these are calendars I subscribe to, maybe they are handled differently?

(In reply to Matthew Saltzman from comment #6)
> I connect through my gmail online account.  It's not so terrible that it
> asks for a password and it should save it in the keyring.  The problem seems
> to be that, because there is no password on those calendars, nothing is
> saved in the keyring.  So (speculating here) the next attempt to read the
> calendar results in a password prompt again.  The null password isn't saved,
> so the process repeats endlessly.  

I did not know I can enter 3rd party Google calendars directly in Gnome-Online-Accounts, I always add my mail account, and just check to enable Calendar part, which adds me an account into evolution, with a calendar sources, which leads to my default Google calendar.

> Another possibility is that it's Google and I use two-factor authentication,
> but the password prompter doesn't know how to handle that.  The Online
> Accounts service now does know how to handle two-factor authentication, but
> because these are calendars I subscribe to, maybe they are handled
> differently?

Aha, right, the 3.8.x doesn't use OAuth for Google calendars, because this was not available in the time of 3.8.x, but 3.10.x is capable to use OAuth, the same as for the GMail. Though I think you can configure the CalDAV calendar with Google's server and two factor authentication too, by generating an application password on Google's site and then enter this to the evolution's password prompt. I really do not think Google let's you subscribe to a calendar without password, at least through CalDAV. >What you can try is to run the calendar factory with CalDAV debugging on and see what it does in the background. You can do it like this:
   $ CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w
and then run evolution and see what new will be shown on the console - if there is any traffic between evolution-data-server and any of the CalDAV servers, then it'll be shown on the console - especially when you get a password prompt there might be something shown.

(In reply to Milan Crha from comment #7)
> (In reply to Matthew Saltzman from comment #6)
> > I connect through my gmail online account.  It's not so terrible that it
> > asks for a password and it should save it in the keyring.  The problem seems
> > to be that, because there is no password on those calendars, nothing is
> > saved in the keyring.  So (speculating here) the next attempt to read the
> > calendar results in a password prompt again.  The null password isn't saved,
> > so the process repeats endlessly.  
> 
> I did not know I can enter 3rd party Google calendars directly in
> Gnome-Online-Accounts, I always add my mail account, and just check to
> enable Calendar part, which adds me an account into evolution, with a
> calendar sources, which leads to my default Google calendar.

Sorry I wasn't clear.  That is how I subscribed to these calendars.  My default Google calendar is fine--it's these additional ones I subscribe to on Google that are the problem.  My point is that I am still being prompted for passwords for them even though (a) I subscribed through my Google account and (b) they don't require passwords to subscribe to even on Google.

> 
> > Another possibility is that it's Google and I use two-factor authentication,
> > but the password prompter doesn't know how to handle that.  The Online
> > Accounts service now does know how to handle two-factor authentication, but
> > because these are calendars I subscribe to, maybe they are handled
> > differently?
> 
> Aha, right, the 3.8.x doesn't use OAuth for Google calendars, because this
> was not available in the time of 3.8.x, but 3.10.x is capable to use OAuth,
> the same as for the GMail. Though I think you can configure the CalDAV
> calendar with Google's server and two factor authentication too, by
> generating an application password on Google's site and then enter this to
> the evolution's password prompt. I really do not think Google let's you
> subscribe to a calendar without password, at least through CalDAV. >What you
> can try is to run the calendar factory with CalDAV debugging on and see what
> it does in the background. You can do it like this:
>    $ CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w
> and then run evolution and see what new will be shown on the console - if
> there is any traffic between evolution-data-server and any of the CalDAV
> servers, then it'll be shown on the console - especially when you get a
> password prompt there might be something shown.

OK Will try this when I have a chance.  I recall in 3.8.x, I had to actually hack the keyring entry with the application-specific password.  Entering it at the password prompt wouldn't work.

You can, of course, subscribe without a password to a calendar in Google if it is configured not to require one.

I took an update on my Fedora 19 system on Friday, and today I have Evolution constantly prompting me for my password, despite the fact that I have the option "Save in my keyring" checked.  I have had it ask me for my password when I sent one email, then ask for the same password again when I sent a second email immediately afterward.  Version information:

Name        : evolution
Version     : 3.8.5
Release     : 2.fc19
Architecture: x86_64
Install Date: Wed 21 Aug 2013 11:36:51 AM CDT

For my case, it seems that what Evo wanted was a Gmail "application-specific password" for my account.  (I have two-level authetication set for my Gmail account.)  So the authentication through the Gnome-shell Online Accounts app was good enough to get my email, but wasn't good enough to get Google calendars I subscribe to with that account.

After authenticating with an app-especific password, I have not been prompted again.

I have not seen the original Problem for a while.

Seems that it disappeared since I have not seen a real fix.

For me we can close this bug.

Thanks for the update. I plan to change password prompts in the upstream version in some future, also to properly support the two-phase authentication natively, not only through GOA, but it'll take some time for sure.