[evolution-kolab] CamelKolabSession: let CamelTCPStreamSSL temporarily accept new server certs
- From: Christian Hilberg <chilberg src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [evolution-kolab] CamelKolabSession: let CamelTCPStreamSSL temporarily accept new server certs
- Date: Tue, 30 Oct 2012 20:06:45 +0000 (UTC)
commit 9b4cf47810ae74c24277b109dade63b8f8bc83bc
Author: Christian Hilberg <hilberg kernelconcepts de>
Date: Tue Oct 30 20:59:36 2012 +0100
CamelKolabSession: let CamelTCPStreamSSL temporarily accept new server certs
* When seeing a new server certificate for the first time,
which it cannot automatically validate by chaining-up the CA,
CamelTCPStreamSSL::ssl_bad_cert() will invoke the
CamelSession::alert_user() function to query the user whether
the certificate should or should not be accepted. In the
evolution-kolab plugin, the collection backend will be the first
one to arrive there, then the cal/book backends, each in separate
processes. Last, Evo itself will arrive in its own CamelSession
implementation's alert_user(), which displays the accept/decline dialog.
The best we can do at the moment is to temporarily accept
the server cert in backend (collection/calendar/contacts)
context, since the certificate is *always* written into the
Camel cert_db by CamelTCPStreamSSL::ssl_bad_cert(), only the
trust level is set according to the user selection in alert_user().
That means we need to act here and cannot just fail to let Evo
handle everything. If we temporarily accept, Evolution will still
ask for certificate accept/decline, and the result will be written
to the cert_db, from where the trust level selection is picked
up on next E-D-S restart
src/libekolab/camel-kolab-session.c | 47 +++++++++++++++++++++++++++++++++-
1 files changed, 45 insertions(+), 2 deletions(-)
---
diff --git a/src/libekolab/camel-kolab-session.c b/src/libekolab/camel-kolab-session.c
index 82db489..0e501dd 100644
--- a/src/libekolab/camel-kolab-session.c
+++ b/src/libekolab/camel-kolab-session.c
@@ -318,17 +318,60 @@ kolab_session_alert_user (CamelSession *session,
const gchar *prompt,
GSList *button_captions)
{
+ gint rval = -1;
+
g_return_val_if_fail (CAMEL_IS_SESSION (session), -1);
/* prompt may be NULL */
(void) button_captions;
/* should we even pop up a dialog from within E-D-S? */
if (prompt != NULL) {
- g_warning ("%s()[%u] (%u) Error: %s",
+ g_warning ("%s()[%u] (%u) \n%s",
__func__, __LINE__, type, prompt);
}
- return -1;
+ /* XXX SSL certificate workaround
+ *
+ * When seeing a new server certificate for the first time,
+ * which it cannot automatically validate by chaining-up the CA,
+ * CamelTCPStreamSSL::ssl_bad_cert() will invoke this function
+ * to query the user whether the certificate should or should not
+ * be accepted. In the evolution-kolab plugin, the collection
+ * backend will be the first one to arrive here, then the cal/book
+ * backends, each in separate processes. Last, Evo itself will
+ * arrive in its own CamelSession implementation's alert_user(),
+ * which displays the accept/decline dialog. Current implementation
+ * of CamelTCPStreamSSL::ssl_bad_cert() does the following, based
+ * on the return value of this function:
+ *
+ * 0: reject the cert in question
+ * 1: temporarily accept the cert in question
+ * 2: permanently accept the cert in question
+ *
+ * all else is regarded "fail and ask again"
+ *
+ * The best we can do here at the moment is to temporarily accept
+ * the server cert in backend (collection/calendar/contacts)
+ * context, since the certificate is *always* written into the
+ * Camel cert_db by CamelTCPStreamSSL::ssl_bad_cert(), only the
+ * trust level is set according to the user selection in alert_user().
+ * That means we need to act here and cannot just fail to let Evo
+ * handle everything. If we temporarily accept, Evolution will still
+ * ask for certificate accept/decline, and the result will be written
+ * to the cert_db, from where the trust level selection is picked
+ * up on next E-D-S restart
+ */
+
+ if (g_slist_length (button_captions) == 3)
+ /* this is some guessing about whether
+ * we're asked for server cert accept/decline
+ * (cannot parse button captions or prompt,
+ * since these will be translated, but bad_cert()
+ * is the only instance calling us - good luck!)
+ */
+ rval = 1; /* temporarily accept, Evo will ask for confirmation */
+
+ return rval;
}
/*----------------------------------------------------------------------------*/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]