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 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 (?)
> From: 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. 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. > 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. 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 Cheers, Stef ___ 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 (?)
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 (?)
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
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 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 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 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 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
[Evolution-hackers] evolution-kolab: Camel.HttpStream in the wild (?)
Hi everyone. Within our evolution-kolab plugin, we need to access the webserver part of Kolab to retrieve free-busy information (no more than simple GET requests needed, but with authentication - as far as we can see atm ;-). The Kolab webserver will answer the GET request with an iCal file containing the free- busy-information. 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)? We would also need to be able to encrypt the HTTP connection using the Mozilla NSS infrastructure. When using "https://";, the Camel.HttpStream will make use of the TcpStreamSSL which in turn uses NSS, is this information still valid? The motivation for my question is that the webserver may ask for a client certificate which will be handled by NSS, so we most probably cannot switch to any other mechanism here. Best regards, and happily accepting input on the issue, 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
