After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 252810 - Accepting a bad SSL cert does not always give access to IMAP folders
Accepting a bad SSL cert does not always give access to IMAP folders
Status: RESOLVED INCOMPLETE
Product: evolution
Classification: Applications
Component: Mailer
1.5.x (obsolete)
Other other
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2004-01-13 05:58 UTC by Tom McLaughlin
Modified: 2012-10-07 06:18 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tom McLaughlin 2004-01-13 05:58:57 UTC
Please fill in this template when reporting a bug, unless you know what you
are doing.
Description of Problem:

On some occassions when connecting to an IMAP account using SSL and after
rejecting a cert warned as bad, a new confirmation window will appear
again.  If you elect to then accept the cert, it will be saved in
~/.camel_cert but evolution will not give you access to your folders for
that account.  You need to exit and restart evolution in order to access
the folders.  This was reproduced with two seperate servers but on some
occassions each server did work correctly.


Steps to reproduce the problem:
1. Add an IMAP account in evolution
2. Exit evolution and remove the ~/.camel_cert directory so that the
program must evaluate a cert on startup.
3. Select "No" when asked the first time to accept the cert.
4. Select "Yes" the second time to accept the cert.


Actual Results:
A cert will now be present in ~/.camel_cert but the IMAP mailbox will show
no folders.

Expected Results:
The user should be able to access their IMAP mailboxes folders.


How often does this happen? 
Often


Additional Information:

Gnome version - 2.5.2


Console output:

[tom@athens tom]$ evolution-1.5
(Killing old version of evolution-data-server...)
 
(evolution-1.5:2543): camel-WARNING **: could not load cert
/home/tom/.camel_certs/49:da:40:8a:fc:44:17:69:eb:2b:0f:cb:31:33:42:a6: No
such file or directory
asked to activate component_id
`OAFIID:GNOME_Evolution_Addressbook_Component:1.5'
Xlib:  extension "RENDER" missing on display "192.168.1.129:1.0".
 
(evolution-1.5:2543): evolution-mail-CRITICAL **: file em-folder-view.c:
line 1932 (emfv_setting_notify): assertion `gconf_entry_get_value (entry)
!= NULL' failed
 
(evolution-1.5:2543): camel-WARNING **: Trying to check NULL OBJECT is
OBJECT 'CamelStream'
 
(evolution-1.5:2543): camel-CRITICAL **: file camel-object.c: line 905
(camel_object_is): assertion `check_magic(o, ctype, TRUE)' failed
 
(evolution-1.5:2543): camel-CRITICAL **: file camel-stream.c: line 226
(camel_stream_printf): assertion `CAMEL_IS_STREAM (stream)' failed
 
(evolution-1.5:2543): camel-WARNING **: could not load cert
/home/tom/.camel_certs/49:da:40:8a:fc:44:17:69:eb:2b:0f:cb:31:33:42:a6: No
such file or directory
Comment 1 Not Zed 2004-01-14 04:15:34 UTC
putting this down to normal, because there's a trivial workaround
(exit/restart) and it should only happen once.
Comment 2 Not Zed 2004-01-15 07:52:40 UTC
ok, this is a race between several commands on the same store
 - em-folder-tree getting a list of folders
 - mail-folder-cache getting a list of folders

if one fails and the other tries again at the right time and succeeds,
then you're left with an inconsistent ui state.

this may be hard to fix unless we try a different model
 - the session emits events about stores?
 - everything done by mail-folder-cache is done by em-folder-tree

the workaround is easy, and once youv'e accepted the cert (which you'd
normally accpet the first time anyway), it doesn't re-occur.
Comment 3 Not Zed 2004-01-15 07:53:42 UTC
(also the store could emit events about itself rather than the session)
Comment 4 Gerardo Marin 2004-01-28 06:12:02 UTC
Retargeting 1.5.3->1.5.4 bug reports. Sorry for the spam.
Comment 5 Not Zed 2004-02-02 06:46:45 UTC
gerardo, this may be one of those ongoing 'known bugs' - its a lot of
work to fix with the current codebase.
Comment 6 Gerardo Marin 2004-02-02 07:44:02 UTC
Moving milestone to something ahead. If 2.1 seems reasonable for you,
please set that milestone.
Comment 7 Not Zed 2004-03-11 08:59:16 UTC
i'm not sure if its even a 2.1, but i'll set it there for now

who knows, some easy solution might come to light.
Comment 8 André Klapper 2005-09-25 01:43:46 UTC
retargetting from very ancient 2.1 milestones to just ancient 2.3 milestones.
it just sucks to click several target milestone values.

sorry for the noise.
Comment 9 André Klapper 2005-11-25 00:12:31 UTC
reassigning stuff that has been assigned to notzed. goodbye, dude. :-/
Comment 10 André Klapper 2012-06-17 12:16:03 UTC
Codebase has vastly changed in the meantime - any idea if this is still an issue in 3.4.2 or 3.2.3?
Comment 11 Tobias Mueller 2012-10-07 06:18:46 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!