Hey Jeffrey, Matthew,
And Jose
This (forwarded message) might be interesting for you guys too: it's
another implementation of camel-certdb.c, but this time for Maemo's
libcst.
I think we should consider thinking about abstracting this a bit better,
so that it's more convenient to provide an all new implementation or to
plug it in.
There is, for example, a GSoc student interesting in doing Seahorse
integration in Evolution. Guessing his work too will overlap.
Mozilla has its own key store, Maemo has its own key store, Seahorse has
a key store, Devices X and Devices Y will probably also have a key store
that is controlled by their specialised UI and that comes with default
installed fingerprints. For example for GMail IMAP, etc.
In my opinion is key signing and storing is more than just putting files
in $HOME/.camel_cert, it's something that depends on the platform a lot.
I would like to see Camel becoming less glued to Evolution, and this is
one of those items that does glue it at this moment.
My personal opinion on this ...
.. is that not Camel but the layer above Camel should solve it (with
perhaps a default solution). For example an Evolution plugin would solve
it in Evolution, or if there's no such plugin default code would.
In Tinymail it would be "implementing a TnyCertificateHandler" and doing
something like:
TnyAccount *acc = ...
tny_account_set_certificate_handler ( acc,
tny_seahorse_certificate_handler_new ());
Any unmodified TnyAccount would be constructed with:
priv->cert_handler = new tny_default_certificate_handler_new ();
This way an E-mail client like Modest could either go for one of
Tinymail's featured certificate handlers, subclass those, or implement a
new one from scratch:
TnyAccount *acc = tny_..._modest_account_new ( ... )
tny_account_set_certificate_handler ( acc,
modest_cst_certificate_handler_new ());
Modest's developer would implement a ModestCstCertificateHandler class
in Modest's layer.
For Camel(-lite) this would mean slashing CamelCertDb and in stead
making an implementation that expects the layer above to fulfil the
current functions (callbacks or a GInterface).
I would of course prefer this to go in Camel upstream rather than yet
again maintaining a large delta of changes between camel-lite and camel
upstream.
Ideas, thoughts?
--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be
--- Begin Message ---
Hi,
This patch adds support for using CST as certificate repository in
camel (tinymail camel backend). CST is the common certificate repository
available in Nokia maemo-based internet tablets.
It's implemented as a fast hack to avoid a big rework of the currently
working implementation.
Of course, it seems all the certdb stuff should be refactored to allow
multiple backends (CST, file certdb, mozilla, whatever). But this adds
provisional support.
About autotools stuff, it only enables the cst support if available and
you use nss ssl implementation (I didn't implement the openssl side
support for camel-certdb-cst, so I'm not sure if it's working).
Changelog entry:
* Added libtinymail-camel/camel-lite/camel/camel-certdb-cst.c.
Implementation of certificates database using maemo libcst. This
makes you can manage certificates using the maemo tablet certificate
manager.
* libtinymail-camel/camel-lite/camel/camel-certdb.h,
libtinymail-camel/camel-lite/camel/camel-private.h: modified to
have a pointer to the CST object in certdb and certificate id in
certificate object in case we compile with CST support.
* libtinymail-camel/camel-lite/camel/camel-tcp-stream-ssl.c:
Modified a bit the code for proper integration with cst (mainly
removing direct access to internal fields).
* libtinymail-camel/camel-lite/configure.ac,
libtinymail-camel/camel-lite/camel/Makefile.am:
Added support for detection and configuration of libcst.
--
José Dapena Paz <[EMAIL PROTECTED]>
Igalia
Index: m4/gtk-doc.m4
===
--- m4/gtk-doc.m4 (revision 3558)
+++ m4/gtk-doc.m4 (working copy)
@@ -9,22 +9,22 @@
AC_BEFORE([AC_PROG_LIBTOOL],[$0])dnl setup libtool first
AC_BEFORE([AM_PROG_LIBTOOL],[$0])dnl setup libtool first
dnl for overriding the documentation installation directory
- AC_ARG_WITH([html-dir],
-AS_HELP_STRING([--with-html-dir=PATH], [path to installed docs]),,
+ AC_ARG_WITH(html-dir,
+AC_HELP_STRING([--with-html-dir=PATH], [path to installed docs]),,
[with_html_dir='${datadir}/gtk-doc/html'])
HTML_DIR="$with_html_dir"
- AC_SUBST([HTML_DIR])
+ AC_SUBST(HTML_DIR)
dnl enable/disable documentation building
- AC_ARG_ENABLE([gtk-doc],
-AS_HELP_STRING([--enable-gtk-doc],
- [use gtk-doc to build documentation [[default=no]]]),,
-[enable_gtk_doc=no])
+ AC_ARG_ENABLE(gtk-doc,
+AC_HE
