Re: [Evolution-hackers] evolution-kolab: Camel.HttpStream in the wild (?)

2010-08-05 Thread Christian Hilberg
Hi again,

On Wednesday 04 August 2010 Christian Hilberg wrote:
 On Wednesday, 04 August 2010, Matthew Barnes wrote:
  On Wed, 2010-08-04 at 16:03 +0200, Christian Hilberg wrote:
   Is there any good alternative to using libsoup which makes use of NSS?
   We're pretty much depending on the (mostly) working NSS infrastructure
   for PKCS #11 and token handling for certificate based client auth.
  That I don't know.  You might want to ask the libsoup maintainer, Dan
  Winship (d...@gnome.org).
 [x] done. I've posted to the libsoup list, see [1]. Maybe we can dig up
 something useful there.

Result: While libsoup should build against the current GnuTLS lib (development 
version, 2.11.0), which has PKCS #11 support since a few weeks now, libsoup 
has no infrastructure for handling client certificates at all [1] and GnuTLS 
does not seem to handle that by itself the way NSS does.

There are efforts to support TLS within GIO context and to provide a plugin 
mechanism (so several security libs could be used) [2], but this will take 
time to be implemented and so it won't help us right now.

This means that we cannot use libsoup for HTTP access since we *must* be able 
to support client certificates. We will have to look for another solution for 
now.

I also do not like the idea of adding yet another dependency to some other 
HTTP lib which has NSS support (like libcurl) too much, but which other 
options do we have? If we used libcurl, then we needed to provide our own 
packaged version which will be linked against NSS, since most distros ship 
only openssl/gnutls variants.

I'll be very grateful for any further input.

Kind regards,

Christian

[1] http://mail.gnome.org/archives/libsoup-list/2010-August/msg4.html
[2] http://mail.gnome.org/archives/libsoup-list/2010-August/msg1.html

-- 
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen
http://www.kernelconcepts.de/


signature.asc
Description: This is a digitally signed message part.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] evolution-kolab: Camel.HttpStream in the wild (?)

2010-08-05 Thread Matthew Barnes
On Thu, 2010-08-05 at 18:30 +0200, Christian Hilberg wrote:
 Result: While libsoup should build against the current GnuTLS lib 
 (development 
 version, 2.11.0), which has PKCS #11 support since a few weeks now, libsoup 
 has no infrastructure for handling client certificates at all [1] and GnuTLS 
 does not seem to handle that by itself the way NSS does.

Hmm, then perhaps CamelHttpStream might be a good stopgap after all.  Be
aware that I have marked it as deprecated and do still plan to remove it
after we transition to WebKit, but perhaps by then Dan's TLS work for
GIO will have landed.

I'm eagerly looking forward to it, myself.

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Camel IMAPX RFC5464 compliance

2010-08-05 Thread David Woodhouse
On Wed, 2010-08-04 at 12:22 +0200, Christian Hilberg wrote:
 Now, I would like to know how we should deal with the issue. We (the 
 evolution-kolab developers) could patch the 2.30 version of IMAPX only to get 
 things running. In this case, would our additions be pulled upstream?
   As an alternative, would anyone like to implement RFC5464 in the current 
 upstream IMAPX so we could try and backport the changes into 2.30?

I would strongly recommend that you do it in the development branch
first, then we can backport it to gnome-2-30.

I've been backporting most IMAPX changes from master to the 2.30 branch;
I see no particular reason why we shouldn't backport METADATA support
too, as long as you're careful not to add new user-visible strings that
would need translation.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers