I guess that gnome-keyring runs properly?

Yeah - for instance, I can ssh around properly (don't have to keep re-entering my passphrase).

It doesn't ask for the password _every_ time it needs it, either. But it's asked more than once.

Been working fine here, but I'm on an older desktop.

Works fine for me here too (I even got rid of ~/.local/share/camel_certs and ~/.local/share/evolution/camel-cert.db file, then started evolution and accepted my certificate. The next start I wasn't asked again.

Not that I see any directly connected change in eds, but does anything change with 3.5.90?

I can't tell yet as the update is not dependency consistent. If you guys can get the mega-update in shape, I can test it.

OK, so I'm on 3.5.91 now. I haven't been using it much as it still has issues with qresync and empty message previews, but testing it now, it doesn't seem to keep asking for my password any more, but it does still seem to ask me to trust my self-signed server certificate a lot. xtian says he's seeing the same.

I have seen this behaviour two days ago with then-current Evo/E-D-S git master,
when initially creating a new IMAP+ account, setting it to use STARTTLS right
away and using a self-signed SSL cert.
I had some issues with the password / SSL cert dialogs back then, so I switched
from STARTTLS back to unencrypted, stored my password in the GNOME keyring, and
re-enabled STARTTLS. Evo now no longer asks for SSL cert confirmation (though I
do not see my self-signed server cert in "my certificates" - but should I?).

Just 2 cent...

(In reply to comment #8)
> I had some issues with the password / SSL cert dialogs back then, so I switched
> from STARTTLS back to unencrypted, stored my password in the GNOME keyring, and
> re-enabled STARTTLS. Evo now no longer asks for SSL cert confirmation (though I
> do not see my self-signed server cert in "my certificates" - but should I?).

Hmm, it's confusing to me (aka I've not much idea what can be wrong, as it works fine for me here).

These certificates are not visible in any UI, as far as I know. They are "managed" only internally, when connecting over SSL.

So I've been using 3.5.92 for a couple of days now. It's not as bad as it was when I reported this, but it's still happening. For instance, I just resumed from suspend and when I switched to Evo, the 'trust this certificate?' dialog was up again. I replied to a mail, and on hitting send, it popped up again.

This is definitely still happening for certificates, but not passwords, as of 3.6.0 on my system. Obviously not happening to everyone, though. What can I provide that would help figure out what's triggering it for me?

I usually get asked to approve the self-signed cert on my mail server at least on every boot and every resume from suspend.

There are couple places where camel stores its self-signed certificates. In previous version (before 3.6.0) it was ~/.camel_certs, which was moved to ~/.local/share/camel_certs. The actual camel-cert.db with your preferences on trust level for mail certificates is stored in ~/.local/share/evolution. You should see your certificate there.

Since bug #606181 the site certificates are handled by a hostname, which is in since 3.5.2. Does it have any negative influence on this bug report?

Having seen that behaviour with 3.6.1+ (current gnome-3-6 branch) again, now and then. Happens inside a 32bit VM for me, cannot reproduce with 64bit VM (each own bare-metal build on Ubuntu/Precise), under XFCE. Seems something is still lurking there.

It's still happening regularly to me. Several times per Evo session it asks me to accept my self-signed server cert.

(In reply to comment #14)
> It's still happening regularly to me. Several times per Evo session it asks me
> to accept my self-signed server cert.

FWIW, are you on 32bit or 64bit? As I cannot reproduce this on my 64bit VM, that would be interesting to know.

64.

Huh. So I think I can see what's going on here.

My SMTP server - postfix - and my IMAP server - dovecot - are using different certs. Not sure if this is a common configuration, or absolutely 'correct' or 'incorrect', but it's the case, I've had it that way for a while, Evo didn't used to have trouble with it, and other apps don't have trouble with it.

I think both certs have very similar / identical attributes - E, CN, OU etc.

Looking at the ~/.local/share/evolution/camel-cert.db file referred to above, it doesn't seem to have *both* certs in it. It keeps switching between the two. When I approve the SMTP server's cert, it overwrites the IMAP server's cert, and vice versa. That's why I keep getting asked to approve certs - they're constantly overwriting each other.

I guess the camel-cert.db is organized by the CN or something like that, and since both certs have the same CN, it doesn't keep them both on file, but only one or the other. Make sense?

Oh, I note that in ~/.local/share/camel_certs I have directories for both certs, identified by fingerprint. If that was the 'old' way of doing it, and that way identified certificates by their fingerprint, that would certainly be consistent with everything I know now. The 'old' way identified certs by fingerprint and kept them in subdirs of ~/.local/share/camel_certs , the 'new' way uses this ~/.local/share/evolution/camel-cert.db file and apparently identifies certs by the associated CN or something like that, and so breaks when two different certs are in play with the same CN or whatever.

I see, it makes sense. The bug #606181 changes behaviour and stores certificates by the host name. I guess we should include also protocol to the host name, for your case, thus the certificate will not be replaced when sending mail.

Created attachment 227629 [details] [review]
proposed eds patch

for evolution-data-server;

The initial bug report mentions that the correct way of doing this is to compare certificates based on both their hostname and fingerprint, though the change there compares based on the hostname only.

This patch compares based on both values. It changes API, unfortunately, though the API is an internal camel API, which is most likely not used by other 3rd party software. The most, I might ask for an API break for the gnome-3-6 branch, if you will find this functional. Please give it a try. Thanks in advance.

Review of attachment 227629 [details] [review]:

No objection to applying this to gnome-3-6, but I'd advise not bumping the libcamel soname as it would force widespread and unnecessary rebuilds of other GNOME packages.

Thanks Adam for testing (had a chat via IRC).

Created commit 0e47137 in eds master (3.7.2+)
Created commit 2928714 in eds gnome-3-6 (3.6.2+)