Red Hat Bugzilla – Bug 1032959
Evolution doesn't follow first-time account setup wizard settings
Last modified: 2014-01-24 04:18:56 EST
Description of problem:
In order to finally make Evolution work, I have removed completely ~/.config/evolution, ~/.cache/evolution, and ~/.local/share/evolution, and restarted evolution. I got the first-time-run account setup wizard and after setting up the Red Hat email account (and expressly checking for availability and selecting GSSAPI as the method of authentication), and finishing the wizard, finally the full Evo window was visible.
Except that, it won't let me go further without entering password. After entering it, I found that the mail account had set password set up as a the mean of authentication.
Version-Release number of selected component (if applicable):
Thanks for a bug report. I cannot reproduce this, the GSSAPI stick for me from the startup wizard. I have 3.8.5-11, but the -11 didn't bring anything significant. Evolution-data-server is 3.8.5-10.
Could you retest with more recent packages, please?
Created attachment 854518 [details]
(In reply to Milan Crha from comment #3)
> Could you retest with more recent packages, please?
The issue of this bug report has been apparently resolved (after running the first run wizard, I get correctly GSSAPI authentication), but another issue arised: when recovering (both via File/Recovery or by unzipping zipfile with ~/.config/evolution/ ~/.cache/evolution/ ~/.local/share/evolution/) Evolution gets confused and claims that my personal IMAP server has unknown certificate (see attached screenshot). Which is weird, because I have actually purchased commercial certificate from StartCom which should be atuomatically recognized by NSS/OpenSSL/whatever else we have in RHEL (and it works perfectly well with Firefox OS Email, which doesn't allow self-signed certificates).
Should I file a new bug or it is known?
Created attachment 854519 [details]
detailed information about the certificate
It is what libsoup returned when trying to connect to the server. I'm not sure which certificate authority database is used in libsoup, I think it uses gnutls instead of nss/nspr for this, which may or may not make the difference.
The CalDAV calendar backend only sets
on the soup's session.
It'll be better to deal with this in a separate bug report, I would even start with libsoup, at least for a clarification where it searches for certificate authorities and so on.
(In reply to Milan Crha from comment #6)
> It'll be better to deal with this in a separate bug report, I would even
> start with libsoup, at least for a clarification where it searches for
> certificate authorities and so on.
Filed as bug 1057509