Re: [Evolution-hackers] evolution-kolab: Camel.HttpStream in the wild (?)
Hi there, On Thursday 05 August 2010 Matthew Barnes wrote: 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. Since we are developing against Evo 2.30, my thoughts are the same. I'll try to wrap up CamelHttpStream usage in a way that should make it easy (hopefully) to replace CamelHttpStream by some true HTTP lib later on. Thanks and kind regards, Christian -- 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 (?)
Hi Stef, On Friday 06 August 2010 Stef Walter wrote: [...] FWIW, gnutls is working on PKCS#11 support. The first bits have been added and I've been working with the gnutls maintainers on some of the remaining parts. I believe libsoup will start using this in the near future. Yes, we've seen that. Sadly, it won't help us right now, but it is good to know that we'll be able to drop CamelHttpStream once this will be working. [...] You might be interested in the talk that I gave at GUADEC which addresses this and outlines our current effort to make things like client certificates and key storage work far simply and reliably across GNOME. http://stef.thewalter.net/2010/07/my-talk-usable-crypto-on-gnome.html We'll check that out, thanks for the bits! :-) Best regards, Christian -- 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 (?)
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 (?)
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] evolution-kolab: Camel.HttpStream in the wild (?)
On Wed, 2010-08-04 at 12:50 +0200, Christian Hilberg wrote: Using the Camel.HttpStream should do the trick - is that correct? I've seen the Camel.HttpStream being used within Anjal (file em-format-mail.c). Is this Camel HTTP part being used somewhere else as well (to be used as another reference)? You would be much better off using libsoup. Camel.HttpStream is only used to retrieve remote images and such for HTML mail. I plan to kill that class as soon as we move to WebKit/GTK+ for HTML rendering. ___ 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 (?)
Hi Matthew, thanks for the prompt reply. On Wednesday, 04 August 2010 Matthew Barnes wrote: On Wed, 2010-08-04 at 12:50 +0200, Christian Hilberg wrote: Using the Camel.HttpStream should do the trick - is that correct? I've seen the Camel.HttpStream being used within Anjal (file em-format-mail.c). Is this Camel HTTP part being used somewhere else as well (to be used as another reference)? You would be much better off using libsoup. Does libsoup make use of NSS (just the newbie's uninitiated question)? Camel.HttpStream is only used to retrieve remote images and such for HTML mail. I plan to kill that class as soon as we move to WebKit/GTK+ for HTML rendering. Hey, thanks for that hint! :-) Maybe it would be wise to mark such classes as deprecated/removal candidate or something in the docs. (Bye)^2, Christian -- 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 (?)
On Wed, 2010-08-04 at 13:28 +0200, Christian Hilberg wrote: Does libsoup make use of NSS (just the newbie's uninitiated question)? It uses GnuTLS for transport layer security. http://www.gnu.org/software/gnutls/ Hey, thanks for that hint! :-) Maybe it would be wise to mark such classes as deprecated/removal candidate or something in the docs. You're right, I'll do that. ___ 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 (?)
Hi there, On Wednesday 04 August 2010 Matthew Barnes wrote: On Wed, 2010-08-04 at 13:28 +0200, Christian Hilberg wrote: Does libsoup make use of NSS (just the newbie's uninitiated question)? It uses GnuTLS for transport layer security. http://www.gnu.org/software/gnutls/ 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. From what I've read I get the impression that GnuTLS' PKCS #11 implementation is still rather experimental (true?), so we would (a) step on even more brittle ground (b) have another lib which we potentially need to configure for cert token use (which, when incompatible with parallel NSS use, probably is a no-go) when implementing/configuring token access for client cert retrieval. Any hints on how to handle this situation? Best regards, Christian -- 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 (?)
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). I will say libsoup has positioned itself as -the- HTTP client/server library for GNOME. Quite a lot of desktop infrastructure is already tied into libsoup, including other parts of Evolution and WebKit/GTK+, so I think you'll be hard pressed to find a better alternative. ___ 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 (?)
Hi Matthew, 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. Thanks and best regards, Christian [1] http://mail.gnome.org/archives/libsoup-list/2010-August/msg0.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
