Bug 31447

Created attachment 40090 [details] [review]
wocky-tls: specify peername at session creation time

This is how gio TLS does it, among other reasons because it lets you
use the SNI extension to tell the server which certificate it should
present.

Created attachment 40091 [details] [review]
wocky-tls: Merge WockyTLSSession and WockyTLSConnection together

to match gio TLS, and because there's not much use in the separation
anyway

Created attachment 40092 [details] [review]
wocky-connector-test.c: don't turn off O_NONBLOCK on the server socket

This is not expected to work, and ends up causing deadlocks under gio
TLS.

There doesn't seem to be any point to it anyway... maybe a leftover
from old code? Or maybe it's only needed for the openssl version

Created attachment 40093 [details] [review]
wocky-test-stream: implement GPollableIOStream

GTlsConnection can only wrap streams that implement GPollableIOStream,
so implement that here to make some of the test cases work.

Created attachment 40094 [details] [review]
wocky-tls: port to gio TLS

A few minor things, marked DANWFIXME, are unimplemented

Created attachment 40095 [details] [review]
hack around a test that doesn't pass with current (master) glib

Created attachment 41319 [details] [review]
wocky-test-stream: implement GPollableInput/OutputStream

update to match the API that actually landed in glib

Created attachment 41320 [details] [review]
wocky-tls: port to gio TLS

port to the API that actually landed

this patch suffers a bit from the lack of GTlsDatabase, which will be fixed in glib very soon. Some of the ickiness is also caused by trying to force various error cases to return the exact same error that the old code did, even when there's another suitable-ish error it could have returned instead.

Review of attachment 40095 [details] [review]:

This one does not apply after Will commit 01811a4a6ed0ac6ad5f9439d12560d787c97570d, Will is reducing the number of ping and increasing the delays which makes me think this patch is no longer required.

Setting URL field to my branch. I've rebased this work against latest Wocky, made GIO another backend (along with GnuTLS and OpenSSL) and ported OpenSSL to new WockyTLS API.

http://git.collabora.co.uk/?p=user/nicolas/wocky.git;a=shortlog;h=refs/heads/gio-tls

Is there a gio plugin for OpenSSL?

(In reply to comment #11)
> Is there a gio plugin for OpenSSL?

Not that I know, but it should be fairly straight forward to take Wocky's bakend and build a GIO plugin.

19:18 < stormer> smcv: for you information, this branch only miss the CRL 
                 support, which was not yet in the GIO API at the time

(In reply to comment #13)
> 19:18 < stormer> smcv: for you information, this branch only miss the CRL 
>                  support, which was not yet in the GIO API at the time

The current theory is that there is not going to be any API for dealing with CRLs, because in general, if you are aware of a CRL, you want it to apply to all applications on the system, so it makes sense for CRLs to be handled in a system-administration-y way (like the default CA list), not on a per-app basis.

(In reply to comment #14)
> The current theory is that there is not going to be any API for dealing with
> CRLs, because in general, if you are aware of a CRL, you want it to apply to
> all applications on the system, so it makes sense for CRLs to be handled in a
> system-administration-y way (like the default CA list), not on a per-app basis.

I agree, also after digging, we don't actually use that "wocky_tls_session_add_crl" anywhere in Gabble, we simply have a unit test covering it. I'll ask Sjoerd if that can be removed or made optional in Wocky API.

Branch updated and ready for review (passes all tests now). Note, I''ve moved back the peername to the call to _verify as we now do all the check manually in the gio-tls implementation.

Anyone to review this ?

(In reply to comment #17)
> Anyone to review this ?

I'll try to get to it soon, but it would be great if a TLS expert (Vivek?) could have a look.