Bug 26685

This is a bug report for the review of the 'xtls' wocky branch, located at [1]. The branch is based upon the 'tls-additions' one, which is posted for review in bug #26507.

The branch probably still needs a bit more love, but I'm posting it here for an initial review before it gets too big.

- how it works
There are some new objects:

WockyDummyJingleNegotiator - an object that does jingle signalling to negotiate an e2e transport, in an interactive way. The API is quite simple, basically you have signals for each step of the jingle handshake as required by XTLS (i.e. session-initiate, session-accept and session-terminate), along with methods that allow you to send such stanzas and reply to stanza received on the WockyPorter. Each signal usually carries with it the jingle ID of the session we're negotiating, and the stanza itself, so that it can be modified/shaped by an external handler if we want to supply more information inside it (see later the description of WockyXtlsHandler). The 'dummy' means that we can only negotiate a TCP connection for now (I did this under Sjoerd's advice, so that I can move on to implementing the higher-level parts sooner), but other than this, this part of the code should not contain any parts specific to XTLS itself, and could be extended to negotiate other kind of transports.

WockyE2EConnector - for this, I took the API of WockyConnector, which connects to a server, and made a similar object that connects to a contact using the jingle transport negotiated by WockyDummyJingleNegotiator. The API consists of a _connect_async() and _connect_finish() pair, that returns a WockyXmppConnection. You can pass a WockyXtlsHandler to the function, more on that later.

WockyE2EListener - this does the opposite job of WockyE2EConnector, i.e. it listens for incoming jingle requests and lets the client accept/reject them. The API is very similar to the connector, and you will get a WockyXmppConnection back.

WockyNegotiatorFactory - as we can have more than a server, and it's also needed to cache WockyDummyJingleNegotiator objects during the lifetime of the jingle sessions, this singleton, which ideally lives in WockySession, does that job.

WockyXtlsHandler - this is the object responsible for actual encryption; its API consists in a 'remote-security-info' signal, that is fired when information about other peer's encryption capabilities are available, and methods to shape the stanzas accordingly to client's encryption choices. Clients are supposed to call either _handle_session_accept() or _handle_session_initiate() providing encryption information in the 'remote-security-info' callback to make the handshake proceed.

There's also some additions to WockySession; expecially wocky_session_add_e2e_connection() should be interesting, which delegates to the session to send session-terminate stanzas and react when the end-to-end WockyPorter is closed.

The objects are quite tightly integrated between themselves, and ideally a client (i.e. a CM) would use the higher-level listener/connector/session APIs and just call _handle_session[initiate/accept] on the handler when encrypting. See the code in wocky-test-xtls.c for an example on how to use the API.

- things that still need to be ironed out
Error handling; right now we fire an "handle-error" signal from the negotiator when something goes wrong, but that's still not hooked-up in the listener/connector objects.
Probably there are some memory leaks.
There are still some FIXMEs in the code.

- one more thing
This commit [2] is probably useful outside of the XTLS branch as well, and could be merged sooner separately; see the git log entry for more details.

[1] http://git.collabora.co.uk/?p=user/cosimoc/wocky.git;a=shortlog;h=refs/heads/xtls
[2] http://git.collabora.co.uk/?p=user/cosimoc/wocky.git;a=commit;h=fc99076406a526b6279295c5c726269df459164e