Jonathan Schleifer wrote:
Am 20.08.2008 um 20:16 schrieb Peter Saint-Andre:I posted that to this list. Did you not read what I said?Seems I don't get it…I was talking about c2c here.And that makes a big difference how?As already discussed here, some clients have problems when it's inbound and not a socket. And they need to handle a stream inside a stream. Clients who can only handle one connection like mcabber will very likely miserably fail.As to TLS encryption of XML streams, Dirk has support for it in his Python code and gloox has some preliminary support (but that was experimental, back when we were first talking about "XTLS"). However, I grant that none of that code is deployed yet.Then why not depoly it so we actually see how it'll perform in the real world?Sure there is. See XEP-0246 and XEP-0247.Sorry? There is ABSOLUTELY nothing about TLS. Or I'm blind.
It's just XML streams as in RFC 3920, with possibly a different underlying transport. Upgrade via STARTTLS and you're done.
But I'll add some examples about that.
And they won't need a lot of changes for ESessions? Please.Not when using Brendan Taylors library, no.
Where can this magical library be downloaded? As I understand it, he's offered to write a C library, but he hasn't done so yet.
For XML Stream in XML, I'm pretty sure some clients might even need changes to the XMPP parser core.
So let's take a poll of client developers then.
You do in Gajim. I don't in Psi, Adium, Exodus, Trillian, Pidgin, or any other codebase. But all of those codebases support TLS and most of them are adding Jingle support, thus enabling negotiation of end-to-end streams, then you just upgrade the stream via STARTTLS. That seems like a lot less work than building ESessions support into all the clients (and no it's not as easy as dropping in a library, because you know that's not how Gajim functions today -- Brendan's C lib is just a promise, not a reality).Yeah, and none of them supports XTLS, so how is that better? :)
Non sequitur.
Or maybe we just all need to use Gajim?No, that's not an option. The solution is to add support to other clients as well :).
So all clients but one will need to be modified. Better for you, but not necessarily better for all the client developers.
We tried to get developers interested in ESessions. Only one client added support, thanks to the Google Summer of Code and the strong work by Brendant Taylor. Every other client developer I approached said "oh ESessions is hard, I need to do all that math and crypto stuff in my client, but I'm just a Jabber developer who's accustomed to XMPP so I'd rather use something that enables me to re-use an existing library". And XTLS enables developers to do just that.
Shall we bet on that?Sure, I'm pretty sure no client has a stable release in a half year that supports it. Not even an alpha. Maybe in SVN and very unstable, but not more.
Well, to make it a fair bet, we'd need to see how long it took Brendan's GSoC 2007 code to make it into a released version of Gajim. Was it first included in Gajim 0.12? If so that was about a year before release. And in fact Gajim 0.12 is still alpha, so that's not an official release:
http://trac.gajim.org/browser/tags/gajim-0.12-alpha1/ChangeLog So half a year isn't right, let's bet on 1 year.
And deployment of TLS is merely theoretical? Yes it is for end-to-end XML streams (so far), but it's not for client-to-server streams or server-to-server streams, and extending that model to e2e streams seems quite reasonable.Why you keep mentioning c2s TLS again and again?
Because it works.
This is totally different. That doesn't need another stream. That doesn't need jingle. That doesn't need the client to handle multiple XML streams at once. Etc., etc., etc. For example, mcabber can only handle one XML stream at once and IIRC, it is not easy to fix that. How should XTLS be done there? ESessions would be possible…
Adducing mcabber as the model for a Jabber client is a bit misleading. /psa
smime.p7s
Description: S/MIME Cryptographic Signature
